bp-activity is off by 5 Hours

[mgkoller]

The Dashboard activity panel adds 5 hours to any activity updates. Seems that it might be an "offset".
"/wp-admin/admin.php?page=bp-activity"

Regular activity updates (activity/) and RSS are displaying correct update times.

Example

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.

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:

http://buddypress.org/support/topic/activity-time-is-gmt-activity-stream-posted-an-update-time-is-incorrect/#post-151962

WP: 3.4.2
BP: 1.6.1

Please let me know how to proceed.

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... ?

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.

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

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.

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

Diff ? Patch ? My fix ?

​https://github.com/shanebp/BP_local_time/commit/d4899dfe2fb24b83ddcf69ce54c52667c20c0cd7

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

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' ?

A similar report:
http://buddypress.org/support/topic/activity-post-time-incorrect-under-ajax/#post-156313

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 :)

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.