BuddyPress.org

All true, however bp_core_time_since() runs gmdate() on both time values, converting them to GMT regardless of the time zone.

Andy, I’ve been working with someone else havign this exact same issues, and here’s what we’ve narrowed down (if it helps).

For instance:

In bp-activity/bp-activity-templatetags.php, about line 491 or so: bp_activity_insert_time_since();

That function returns a value through a filter, which has a value created by the function bp_core_time_since();

That function is is ./bp-core.php, around line 1329 or so.

In this function, something quirky is going on, but not “always”.

Thus far, it only seems to be related to activity updates, although it could be more?

(Just created a group, it did it too, and shows 6 hours ago in the activity feed.)

So, I’m putting some echo’s and a die in the time_since function.

Here’s the output:

date passed: 1264065210

As passed into function. ($older_date)

date strtotime: 1264065210

The date passed is run through this:

<?php $older_date = strtotime( gmdate( 'Y-m-d H:i:s', $older_date ) ); ?>

This does nothing to the date passed. The string is the same.

newer_date: 1264086810

This is generated if there is not a $newer_date passed into the function to compare the older_date to.

Code:

<?php $newer_date = ( !$newer_date ) ? ( strtotime( gmdate( 'Y-m-d H:i:s' ) ) + ( 60*60*0 ) ) : $newer_date;?>

This produces, for the first time, a different time string, which is 21600 seconds ahead of the current server time.

since: 21600

The difference between the newer_date, and the older_date.

21600 seconds, or 6 hours, which is the difference between my server time and GMT.

current_time: 1264065210

This is just time() from the server. (Matches what was passed in)

– The date passed into the function is the current server time.

– The “newer_date” is generated as GMT.

So now, the question is this.

Theoretically, if the server time is ahead of GMT, the following will fail:

<?php if ( 0 > $since ) ?>

This is checked right after the difference between the date passed (older_date) and the newer_date.

As the date passed in would be ahead of GMT (current server time), and newer_date will always be GMT if it is created within the function.

Soooo…… does this look trac worthy?

Not sure if I can contribute, but I also have this problem.

WPMU 2.9.1.1

BP r2400

In wp_signups a user has

activated: 2010-01-22 03:06:39 (GMT)

In wp_bp_activity it’s

date_recorded: 2010-01-21 19:06:39 (America/Los_Angeles)

In the activity stream is say “8 hours ago.” I’m not sure what the code does but it seems that when the time is moved to the activity table it’s converted to local time rather than staying in GMT.

If I manually update wp_bp_activity to

date_recorded: 2010-01-22 03:06:39

the activity stream works as normal.

Hope that makes sense and helps.

Hmm, if we can get all this in trac and I’ll see if I can get it fixed, strange. Thanks for the debugging info andrea_r very useful.

@Bbrian017 That ticket is still open which means it isn’t fixed yet. I attached a screenshot to that ticket just to help clarify the situation I was having, which is exactly what you’re experiencing.

I’m browsing through the code to see if I can fix it, but it’ll probably take someone a lot smarter than me. Don’t fret though, it will be fixed in due time.

thks ap that works! ~

https://trac.buddypress.org/changeset/2416

Yes!… i’ve tested that update backwards and forwards.. it will fix your issue.