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

[DJPaul]

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.

[wpmirwin]

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.

[shanebp]

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

[boonebgorges]

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.

[shanebp]

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

[boonebgorges]

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.

[shanebp]

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

[shanebp]

Diff ? Patch ? My fix ?

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

[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.
• WP has a more thorough function get_date_from_gmt() that might be better to use

[shanebp]

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

[shanebp]

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

[DJPaul]

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

[mgkoller]

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.

[trishasalas]

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.

[trishasalas]

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.

[trishasalas]

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.

[mgkoller]

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.

[wpmirwin]

The update also works on my older setup. WP 3.4.2 / BP 1.6.1. Thank-you!

[boonebgorges]

OK, I see what's going on here. Thanks for the patch, trishasalas. I'm going to make a mod to make sure that it remains localizable.

[boonebgorges]

In 7240:

Use get_date_from_gmt() when displaying dates on Activity Management panel

Dates were previously showing up in UTC. The problem only arises in on this
Dashboard panel because elsewhere in BP, bp_core_time_since() is used for
activity timestamps, and the latter function does the necessary UTC conversion.

Fixes #4573

Props shanebp, trishasalas