BuddyPress

I recently updated buddypress to 1.2.6 version and I noticed that the Birthday xprofile field I was using is showing incorrect date.
For Eg: In edit profile I save date of 29 Sep 1980 then in profile view it shows 28 Sep 1980. Day is offset 1 backwards!!
Is this know bug, any workaround to resolve this.

Thanks!

I’m seeing this as well. An odd aspect of this is that the “edit profile” interface is pre-populated with the correct date.

My workaround was to set the WP time zone to UTC, comment out my ini_set('date.timezone', 'Pacific/Honolulu'); in wp-config.php and empty the WordPress cache. I don’t particularly like this move, however.

Yes John, It worked for me too. Thanks!

Hi,

The problem is that at function bp_format_time, lines 819-823 the code uses a time offset.
Don’t know why it does that, but it is causing the error.

// Get GMT offset from root blog
	$root_blog_offset = get_blog_option( BP_ROOT_BLOG, 'gmt_offset' );

	// Calculate offset time
	$time_offest = $time + ( $root_blog_offset * 3600 );

A quick fix is to add this code after line 824, but I don’t know what it will break.

$time_offest = $time;

Another issue is that date( 'F j, Y ', $time_offest ); is not translated.

I created a bug ticket for this: http://trac.buddypress.org/ticket/2779

This should be working if you’ve set the timezone correctly in your Settings -> General screen. Can you confirm you have set it appropriately?

I am having this same issue. When you click on Activity – it is off by 5 hours. So if a member had joined 2 minutes ago, it says they joined 5 hours and 2 minutes ago.

My times are set correctly in the Settings>General screen. In fact I changed it to a different time and back again to see if that would help and no.

I couldn’t find the ini_set(‘date.timezone’, ‘Pacific/Honolulu’ in Wp-config. Pls. helP!

It doesn’t matter if you have your UTC offset number picked or your time zone city picked in Settings/General. Either way, the date will still be one day earlier in public view than you set in edit view. Someone has already identified the problem source code. It does have to do with the time offset calculation, but that was about as much as I could understand.

Everyone: if you think you’ve found a bug in BuddyPress 1.2.7, and you’ve disabled all others plugins in an attempt to isolate the problem to BuddyPress, please make a report on http://trac.buddypress.org. You can use the same username and password that you do for this site.

If you can include clear, step-by-step instructions, it will make it more likely for a developer to confirm, test and fix the issue

I can confirm the problem. The issue occurs if you have a negative GMT offset. Since xprofile dates are saved for midnight of the chosen day, anyone with a negative GMT offset will have their date shifted backwards, which then displays as the day previous to the one chosen.

ie –
Date Chosen: January 4th, 2011
Saved in Database as : January 4th, 2011 at 12:00am GMT
Timezone: Central Standard Time (-0600 GMT)
After bp_format_time(): January 3rd, 2011 at 6:00pm CST

I’ve added a patch to http://trac.buddypress.org/ticket/2779 to fix the issue.

Confirmed on the trunk. Brandon’s diagnosis and fix looks right.

It’s been fixed in the trunk: http://trac.buddypress.org/changeset/3651 If you’re having the problem on 1.2.7, you should be able to fix it by making the following changes:
- In bp-xprofile/bp-xprofile-filters.php, change line 81 to
$field_value = bp_format_time( $field_value, true, false );
- In bp-core/bp-core-templatetags.php, change line 815 to
function bp_format_time( $time, $just_date = false, $localize_time = true ) {
and replace line 820 with the following lines:

$root_blog_offset = false;
if ( $localize_time )
      $root_blog_offset = get_blog_option( BP_ROOT_BLOG, 'gmt_offset' );

Thanks to Brandon for the fix.

Guys did you notice I had logged a bug for this earlier in this thread? http://trac.buddypress.org/ticket/2779 It appears someone else checked-in a fix as well. Not sure if they’re going to step on each other so you may want to check.

Unbelievably enough BuddyPress 1.2.8 still carries these bugs. Hey guys! Let´s fix it in the core BP available for download so that we can avoid fixing it each time we get an upgrade.
Thanks