I did a little more digging into this. OK, a lot of digging into this.
There is a conflict with the timestamps being generated, although I do not have an answer at this time as to why.
After running various tests on this, from directly within the bp_core_time_since function, the only real results I can see is that the date passed in ($older_date) is offset by the timezone from GMT, where when the $newer_date is created, there is no offset from GMT.
So if you're 6 hours behind GMT, the $older_date will be 6 hours behind the freshly generated $newer_date.
Yes, $older_date does have a gmdate applied to it, and is then converted back to a timestamp from that result.
However, the value remains unchanged.
Thus, the difference between the two times will always be at least the time offset from GMT.
I was able to take the $older_date and add 6 hours to it, which then produced the desired time output.
Before:
$older_date = strtotime( gmdate( 'Y-m-d H:i:s', $older_date ) );
After:
$older_date = strtotime( gmdate( 'Y-m-d H:i:s', $older_date ) ) + (60*60*6)
That isn't a true solution, just showing what I had to do to get it up to speed.
It's 60 seconds * 60 minutes * 6 hours, to get the number of seconds the $older_date timestamp was off by.
Again, not a solution. Just a way to quickly work around the problem.
The real interest is why is the older_date offset 6 hours (behind), even after the gmdate conversion.
With everything I ran though, including testing in just a plain, non-wp/bp php file, I can't say anything was found that really adds to this.
I can say that If I printed the timestamps used in bp_core_time_since, then used those in the plain php file, that the output results were different.
Whether the underlying issue is php/server config, with WP (it did this on a plain MU 2.9.1.1 install as well) trying to fix it, or if it's something just really weird somewhere within the WP or BP core, I can't say.
I'd dig into it more for ya, but I'm a bit out of time. Keep an eye on that trac ticket to see what comes of it.