[kronolith] timezone problem in Calendar Views

[Systeembeheer BCS]

Citeren Tomi Orava <tomi.orava at ncircle.nullnet.fi>:

> 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

no, I use Ubuntu 12.04LTS, PHP Version 5.3.10. In Ubuntu 12.04 there  
is no default date.timezone setting in php.ini and PHP does not pick  
up the systems timezone from /etc/timezone either, leaving php  
timezone undefined by default. Could be 14.xx behaves in the same way,  
haven't tested that yet.

Now the underlying problem is that when Nag is disabled, Kronolith  
ignores the timezone setting in the user preferences. Instead it will  
fall back to the php timezone. But if no timezone is defined in php  
either Kronolith falls back to UTC as a last resort.

Without a timezone defined, new events will be stored with event times  
exactly as entered. The same happens to existing events that are  
edited. As a result all those events are stored with the wrong times  
and will need manual correction in the database after resolving the  
issue. If you know when Nag was disabled you can use the  
event_modified field in kronolith_events to determine which events in  
the database need correction.

My workaround is to manually set date.timezone to my local timezone in  
php.ini. All my users are in the same timezone so it is not an issue  
that they can't define their own timezone in their preferences anymore.

To reproduce:
- set $conf['resource']['params']['utc'] = true in kronolith/config/conf.php
- disable Nag (using registry.local.php in horde/config)
- log in and open the calendar. All events now appear in the php  
timezone, or when no php timezone is set, in UTC. Changing the user  
timezone in the user global prefs has no effect anymore.



>
>
> -- 
> kronolith mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: kronolith-unsubscribe at lists.horde.org