[kronolith] timezone problem in Calendar Views

[Tomi Orava]

Quoting Systeembeheer BCS <adje at bezoekerscentrumsonsbeek.nl>:


Hi,

>> Figured it out. Turns out there are 4 variables that influence the way
>> kronolith stores, displays and edits calendar items:
>> 1. default timezone of the user as set in global prefs> locale and time
>> 2. timezone set while entering the event
>> 3. timezone set in php/apache
>> 4. nag on/off
>>
>> Assuming the timezone settings have 2 possibilities (default or
>> Europe/Amsterdam) this results in 16 possible scenarios. Tested them one
>> by one resulting in the table below. In each case I entered an event
>> starting at 10:00. The table lists the times as they are displayed in
>> the calendar views, as the show up in the event editor and as they are
>> stored in the sql dbase.
>>
<snip>

>> I tested with setting timezones in php.ini before but somehow missed
>> this all, too many variables and to much noise from events that were
>> stored incorrectly.
>>
>> Might be a good idea to fix this in Kronolith so the the users tz is
>> always taken into account. Could prevent similar disasters for other
>> users in the future
>>
>> Thanks all for your contributions, I'll start thinking now on how to fix
>> my database.

<snip>

Out of curiosity, where you by any chance using Ubuntu 14.xx for the tests ?
I seem to have hit this very same problem myself without any clear reason
for this wierd display behaviour in GIT Trunk. This system (Git Master) worked
just fine in july, early august with Ubuntu 12.04.

In my case, I can see that all the new kronolith events are stored in  
database in
_current_ time, not in UTC, even though the "conf[resource][params][utc]" is
enabled. When viewed through the kronolith web view an event that was  
supposed to
be on 14:30 is displayed 3 hours later (Helsinki offset from UTC) at 17:30.

I currently suspect that as ubuntu is patching its php5 with the patch
"use_system_timezone.patch", it might somehow mess up the times that are
used in storing the events into mysql db.

Tomi Orava