Running WP 3.0.1 with a child theme of the BP default, just upgraded to 1.2.6 and I’ve confirmed that the GMT time lag still exists for private messaging.

I believe Ticket 2203 was supposed to fix this and was committed to the 1.2.6 release. Help?

[@hnla Participant 15 years ago]

I really hope you’re wrong about that as this ongoing issue was meant to have been corrected once and for all in 1.2.6.

[@paulhastings0 Participant 15 years ago]

I’m afraid so.

But if my memory doesn’t betray me, I think it’s a different part of the private messaging system that’s showing the wrong time now.

[@hnla Participant 15 years ago]

it’s displaying utc time by the looks of things at least my time stamp is an hour behind our present utc +1

[@hnla Participant 15 years ago]

checking and on the dev install I was working on I hadn’t set local time in WP settings

[@djpaul Keymaster 15 years ago]

Let me know what you discover, hnla

[@hnla Participant 15 years ago]

Not looking good having set my local time correctly and WP settings showing UTC and my local time messaging time stamps have now jumped ahead of my local time by 1 hour

[@djpaul Keymaster 15 years ago]

Alas, both of you are correct.

[@hnla Participant 15 years ago]

trying to track down bp_core_current_time() my batch find locates references to it but I can’t find actual parent function

[@djpaul Keymaster 15 years ago]

bp core, line 1312

[@hnla Participant 15 years ago]

cool cheers.

this is/was the relevant ticket I guess?

https://trac.buddypress.org/ticket/2203

[@djpaul Keymaster 15 years ago]

Yes

[@hnla Participant 15 years ago]

Thinking the issue lies with:

/messages/messages-loop.php

bp_message_thread_last_post_date()

function lives in:
/buddypress/bp-messages/bp-messages-templatetags.php: line 288

would guess at the filter

bp_format_time(get_date_from_gmt(

is possibly to blame but will have to see if the ticket sheds light on it

[@hnla Participant 15 years ago]

Fix is simply that

bp_format_time(get_date_from_gmt(

should have been changed but likely missed to:

bp_core_current_time(get_date_from_gmt(

[@hnla Participant 15 years ago]

Nope that isn’t correct

can’t be ‘current’ time

[@djpaul Keymaster 15 years ago]

I think you’re half right – testing a fix.

[@hnla Participant 15 years ago]

I’m in the right area but run out of things to test tried bp_core_time_since but that we know works but returns unformatted plain time since and that doesn’t look correct so it must be the get_date_from_gmt function ?

[@djpaul Keymaster 15 years ago]

http://dl.dropbox.com/u/13733379/omgpizza.patch

Can people test that please?

[@hnla Participant 15 years ago]

That seems to have done the trick paul

that strtotime is one of those php functions I never seem to remember

[@djpaul Keymaster 15 years ago]

If @paulhastings0 can confirm it works, I’ll put it in.

[@hnla Participant 15 years ago]

@paulhastings0 @paulhastings0 @paulhastings0

Test please, you dragged this up

[@pisanojm Participant 15 years ago]

@djpaul @hnla

I can confirm that this works… I had exact same issue with timestamp OMGPIZZA patch fixed it.

[@djpaul Keymaster 15 years ago]

Cool. It’s in the 1.2 branch now. It’s not up to me but I suspect we may do another release in due course to put this in and any other fixes we find.

[@pisanojm Participant 15 years ago]

@djpaul I agree… probably a 1.2.61 or something… It seems like there are a couple of other little “bugs” that should have been cleared cropping up as I read through the forums… Thanks for the fix.

[@paulhastings0 Participant 15 years ago]

@hnla @djpaul So sorry yall, I’ve been at a conference that past few days with limited web access and then had an all-day meeting today. I’ll take a spin with it tomorrow.

[@paulhastings0 Participant 15 years ago]

@djpaul @hnla So far so good. You mentioned that this is now in branch, but does that mean it’ll make it into 1.2.7 or do we need to do something more in the Trac?