Skip to:
Content

#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@…

Description

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
http://i.imgur.com/fl59h.png

Attachments (3)

bp-activity-time-off.jpg (41.9 KB) - added by trishasalas 11 months ago.
bp-activity-time-off-admin-screen.jpg (23.8 KB) - added by trishasalas 11 months ago.
4573.patch (1003 bytes) - added by trishasalas 10 months ago.

Download all attachments as: .zip

Change History (26)

comment:1 DJPaul18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:2 wpmirwin15 months 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:

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.

comment:3 boonebgorges14 months ago

  • Milestone set to Awaiting Review

comment:4 shanebp14 months 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... ?

comment:5 shanebp14 months ago

  • Cc sam3dus@… added

comment:6 boonebgorges14 months 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.

comment:7 shanebp14 months 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

comment:8 boonebgorges14 months 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.

comment:9 shanebp14 months 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

Last edited 14 months ago by shanebp (previous) (diff)

comment:11 shanebp14 months ago

  • Keywords has-patch dev-feedback added

comment:12 follow-up: boonebgorges14 months 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

comment:13 in reply to: ↑ 12 shanebp14 months 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' ?

Last edited 14 months ago by shanebp (previous) (diff)

comment:15 DJPaul12 months 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 :)

comment:16 mgkoller11 months 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.

Last edited 11 months ago by mgkoller (previous) (diff)

comment:17 trishasalas11 months 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.

comment:18 trishasalas10 months 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.

comment:19 follow-up: trishasalas10 months 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.

trishasalas10 months ago

comment:20 in reply to: ↑ 19 mgkoller10 months 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.

comment:21 wpmirwin10 months ago

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

Last edited 10 months ago by wpmirwin (previous) (diff)

comment:22 boonebgorges10 months ago

  • Milestone changed from Awaiting Review to 1.8

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.

comment:23 boonebgorges10 months ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.