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.
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 https://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: https://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? https://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
Confirmed. My temp fix from Boone was overwritten by the original erroneous code as well 
I can confirm it too, after updating to 1.2.8 the date selector problem is back showing dates one day earlier.
So what is the resolution to this? I can confirm that 1.2.8 is still giving the same problem as well. I’m not an expert code writer, so I’m unlikely to be able to go in and edit the code, and all the jargon on the trac site only shows that this was assumed fixed, the problem closed, and nothing ever came of it.
It’s been fixed in trunk, but not in the 1.2 branch. If you want to try applying the patch to your site, try applying these changes to your files: https://buddypress.trac.wordpress.org/changeset/3651.
Couldn’t see why that changeset link was coming up not found. Hard to spot wayward stray ‘full stops’ , hand typing it will get you everytime
