Opened 12 years ago
Closed 12 years ago
#4573 closed defect (bug) (fixed)
bp-activity is off by 5 Hours
Reported by: | mgkoller | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | 1.8 | Priority: | normal |
Severity: | normal | Version: | 1.6.1 |
Component: | Activity | Keywords: | |
Cc: | sam3dus@…, trisha@… |
Attachments (3)
Change History (26)
#1
@
12 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
12 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Not sure if this trac ticket should be re-opened, but I'm experiencing the same problem. In my case, the Activity time seen via WP Admin is also 5 hours ahead of local time. But, I think being 5 hours ahead is only due to my timezone being GMT -5 (EST). i.e. It seems like the GMT time from the Activity Record in the DB is being used directly rather than being converted to local time.
Also, in my case (different than original trac ticket) the regular Activity Stream updates (activity/) are not correct either - but the problem is different! The "user posted an update <n days/minutes/seconds> ago" is 5 hours behind local time. i.e. almost as if the conversion from GMT to local time is being done twice to -10 (?).
A complete overview of the what I've observed is already here:
WP: 3.4.2
BP: 1.6.1
Please let me know how to proceed.
#4
@
12 years ago
Activity time seen via WP Admin is also 5 hours ahead of local time
I can confirm that it is 'off' by the difference between local time and gmt.
In a vanilla install of trunk-6829
I think all these 'time is off' issues might be related to
function bp_core_current_time( $gmt = true ) { in bp-core-functions.php
Why is $gmt = true ?
Wouldn't setting it to false solve a lot of problems?
And be easier than filtering it against 'local time' - which doesn't seem to happen, at least in bp-activity-admin.php
I use current_time('timestamp',0) whenever I need to stamp something. Works great for all client installs.
Maybe bp_core_current_time() is passed a 'false' sometimes but not others?
I can spend some time on this issue.
But first, I'd like confirmation that I'm not missing something.
So, filter it or just default $gmt to local or... ?
#6
@
12 years ago
- Milestone changed from Awaiting Review to Future Release
Wouldn't setting it to false solve a lot of problems?
It's not as simple as that. Of all BP users, only a very, very small percentage have reported this kind of problem. (FWIW, I've seen it myself on a site I was managing, but only on one.) This alone suggests that the problem is not simply BP, but it's some combination of BP+WP+PHP+something else in the server environment.
That said, the question could certainly use another set of eyes, so please feel free to look deeper into it. In particular, if you can find a discrepancy between the way time is handled in activity vs in other components, please bring it to our attention.
#7
@
12 years ago
Can I ask what advantage there is to always using GMT instead of local time ?
And is the time ever correct (iow. local) in the screen created by bp-activity-admin.php ?
It's 'off' by gmt on both servers where I have a 1.7 install.
I don't see how it could ever be correct, except in parts of Britain lol, because it simply formats the date_recorded entry. This is ~Line 1307 in bp-activity-admin.php
#8
@
12 years ago
Can I ask what advantage there is to always using GMT instead of local time ?
The most important thing is to use one time and then to be consistent about it. UTC has the advantage of portability: if you move to a different server or whatever, you can change the display values by changing a single setting.
And is the time ever correct (iow. local) in the screen created by bp-activity-admin.php ?
Yes, this looks like a bug. We should be running everything through a function that converts to local time.
#9
@
12 years ago
The most important thing is to use one time and then to be consistent about it.
Sure, but local time is good enough for WP.
Why not BP? No biggee, but I've always wondered about that gmt=true in BP.
Will submit a patch attempt over the weekend for bp-activity-admin.php
#10
@
12 years ago
Diff ? Patch ? My fix ?
https://github.com/shanebp/BP_local_time/commit/d4899dfe2fb24b83ddcf69ce54c52667c20c0cd7
#12
follow-up:
↓ 13
@
12 years ago
Thanks for the patch. Two things:
- Before applying a fix to this one location, we need to do a thorough sweep to figure out why problems are arising here but not elsewhere.
- WP has a more thorough function
get_date_from_gmt()
that might be better to use
#13
in reply to:
↑ 12
@
12 years ago
Replying to boonebgorges:
Thanks for the patch. Two things:
- Before applying a fix to this one location, we need to do a thorough sweep to figure out why problems are arising here but not elsewhere.
Where else is the time explicitly stated, as opposed to '...days ago' ?
- WP has a more thorough function
get_date_from_gmt()
that might be better to use
I used the 'current_time' function because it always gets the local timezone, if set.
But get_date_from_gmt()
relies on 'gmt_offset' which, don't know why, is often empty in the db value column for that option. Clue ?
Maybe 'bp_format_time()' in bp-core-template.php should use 'current_time' instead of 'gmt_offset' ?
#15
@
12 years ago
- Keywords has-patch dev-feedback removed
- Milestone changed from Future Release to Awaiting Review
I don't want to leave this ticket in future release milestone as we've not figured out how to recreate this issue (or if it's a BP bug); moving back to awaiting-review for more review :)
#16
@
12 years ago
To recreate this issue, post a activity update in BuddyPress. I used BuddyPress 1.7.1 on WordPress 3.5.1 (both were new installs using the default Twenty Twelve theme). Look at the activity, mine says "admin posted an update right now" My computer says 1:50 pm. Now when I look at that same update in Dashboard > Activity, the time is displayed " Submitted on May 14, 2013 at 6:50 PM " , It is off by 5 hours. I have tested this issue on 5 separate computers and on multiple servers, with this same issue happening every time.
#17
@
12 years ago
- Cc trisha@… added
I just confirmed this on my dev install. I'm attaching screenshots. The time is indeed 5 hours off. I'm going to look at the patch and see about using get_date_from_gmt() like @boonegorges mentioned.
#18
@
12 years ago
This can be fixed using this block of code at line 1300 in bp-activity-admin.php
printf( __( 'Submitted on <a href="%1$s">%2$s at %3$s</a>', 'buddypress' ), bp_get_root_domain() . '/' . bp_get_activity_root_slug() . '/p/' . $item['id'] . '/', get_date_from_gmt( $item['date_recorded'], 'F j, Y' ), get_date_from_gmt( $item['date_recorded'], 'g:i a' ) );
Tested in WordPress 3.6 beta 3, Twenty Thirteen Theme, BuddyPress 1.8 beta 1
I'll submit a patch later tonight or early tomorrow.
#19
follow-up:
↓ 20
@
12 years ago
A few additional notes; I tested using both my local time and UTC time in Wordpress settings. I also tested with the server set to both local time and UTC time. Nothing made a difference, the time was always 5 hours off. This was the only place I had any success.
#20
in reply to:
↑ 19
@
12 years ago
Replying to trishasalas:
Attachment 4573.patch added
Working on my Localhost (MAMP) WordPress 3.5.2 / BuddyPress 1.7.2, Will test on live server later on. Thanks for the patch.
We've not seen any reports recently about timezone offsets; it's probably a misconfiguration on your WordPress site, or on the webserver. If you could post on our support forums at http://buddypress.org, we can work through some common causes and try to help you.
If it turns out it's a bug in BuddyPress, we'll re-open this ticket.