Upcoming Calendar Events sidebar applies timezone difference two times

To be more precise, the only modification I have made is to the strftime string on line 358 of hooks.php:

FROM

$c_time = gmstrftime( '%x', $event['_start_time'] );

TO

$c_time = gmstrftime( '%A %d.%m. %H:%M', $event['_start_time'] );

The bug can be reproduced just as well with a completely unmodified hooks.php :

By setting my user accounts timezone to something that makes an event take place near midnight (eg. 23:30) for me, the sidebar will show the event taking place on the following day, hence proving that the 'doubling' of the timezone difference takes place regardless of the strftime string.

This sounds like a duplicate, but in any event the times are displaying correctly for me locally.

Just to verify.. I think you're right about this being a dupe.. But..

What's happening. You enter an event for 23:30 GMT -5

It's stored in the DB as

2012-06-02 04:30:00

Which is correct.

It's stored in the cache as

            [event_start_date] => 2012-06-01 23:30:00

Which is also correct-ish.

BUT.. the hooks.php file has this

                if( !$u['event_all_day'] )
                {
                    if( $this->memberData['member_id'] AND $this->memberData['time_offset'] )
                    {
                        $u['_start_time']    = $u['_start_time'] + ( $this->memberData['time_offset'] * 3600 );
                    }
                    else if( !$this->memberData['member_id'] AND $this->settings['time_offset'] )
                    {
                        $u['_start_time']    = $u['_start_time'] + ( $this->settings['time_offset'] * 3600 );
                    }

Which, takes the user offset out again.

So.. The problem here looks like the event start time is cached with the event timezone already taken into account.

If you remove the above re-offset.. It works fine.. So long as the user viewing the event is in the same timezone as the event starter.

So.. The long and short of this is that the date is cached WITH the offset applied. Which.. That seems to be the problem, because, without the event timezone that it's cached in noted.. You can't back it out and properly apply the actual user offset.

I see the same thing still happening, so it's apparently not fixed. I've made adjustments to the caching routine to not perform the TZ offset.