[kronolith] timezone problem in Calendar Views
Systeembeheer BCS
adje at bezoekerscentrumsonsbeek.nl
Sun Jun 22 20:31:34 UTC 2014
table got terrible messed up in plain text, sorry for that. New try in
html
ROW TZ EVENT TZ USER TZPHP NAG VIEW EDITOR
TIME DB TZ DB
1 default default not set off 10 10 10
none
2 EA default not set off 8 10 8
EA
3 default EA not set off 10 10 10
none
4 EA EA not set off 8 10 8 EA
5 default default EA off 10 10 8
none
6 EA default EA off 10 10 8 EA
7 default EA EA off 10 10 8 none
8 EA EA EA off 10 10 8 EA
9 default default not set on 10 10 8
none
10 EA default not set on 10 10 10
none
11 default EA not set on 10 10 8
none
12 EA EA not set on 10 10 8 EA
13 default default EA on 10 10 8
none
14 EA default EA on 10 10 8 EA
15 default EA EA on 10 10 8 none
16 EA EA EA on 10 10 8 EA
Citeren Systeembeheer BCS <adje at bezoekerscentrumsonsbeek.nl>:
> 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.
>
> TZevent TZ user TZ php NAG
view
> editor db db
>
time tz
> default default not set off
10 10
> 10 none
> EA default not set off 8
10 8
> EA > wrong time display in cal view
> default EA not set off 10
10
> 10 none
> EA EA not set off 8
10 8
> EA > wrong time display in cal view
> default default EA off 10
10
> 8 none
> EA default EA off 10
10 8
> EA
> default EA EA off 10
10 8
> none
> EA EA EA off 10
10 8 EA
>
> default default not set on
10 10
> 8 none
> EA default not set on 10
10
> 10 none
> default EA not set on 10
10 8
> none
> EA EA not set on 10
10 8
> EA
> default default EA on 10
10 8
> none
> EA default EA on 10
10 8
> EA
> default EA EA on 10
10 8
> none
> EA EA EA on 10
10 8 EA
>
> There are 2 scenario's in which kronolith places an event at another
> time in the calendar views then the entered time: rows 2 and 4.
>
> The result of row 2 is somehow logical, with no timezone specified in
> neither user settings nor php Kronolith has no clue and assumes the user
> is at UTC (/etc/timezone seems not to be used by Krono). So when
> entering an event with tz E/A it subtracts 2 hours of the entered time
> to get UTC and stores this time.
>
> The result of row 4 however does not make sense and is the first part of
> the problem I reported. Looking closely at the results you'll notice
> that with Nag disabled, the timezone setting of the user is ignored
> while with Nag enabled it is taken into account. This explains this
> behaviour.
>
> The other problem is that Nag being enabled yes/no effects the way
> events are stored in the database (compare rows 9-12 with 13-16). This
> is a more sneaky problem as it will mess up things when Nag is disabled
> after the events were created and you will not notice until you do
> disable it. This is the second part of my problem and caused my database
> corruption with wrong event times.
>
> The solution for now would be to always specify the timezone in php.ini,
> at least when installing a new system. However be careful on existing
> systems as changing it can mess up things in the existing calendar
> events.
>
> 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.
>
> Citeren Systeembeheer BCS <adje at bezoekerscentrumsonsbeek.nl>:
>
>> Citeren Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Systeembeheer BCS <adje at bezoekerscentrumsonsbeek.nl>:
>>>
>>>> Citeren Arjen de Korte <arjen+horde at de-korte.org>:
>>>>
>>>>> Citeren Systeembeheer BCS <adje at bezoekerscentrumsonsbeek.nl>:
>>>>>
>>>>>> Ok, have been digging a bit deeper into this one. Changing timezones
>>>>>> in
>>>>>> php.ini made no difference. But I remember Kronolith working
>>>>>> correctly when
>>>>>> I first installed the system, so I decided to copy the complete
>>>>>> present
>>>>>> system config to a test machine and spend some late hours trying
>>>>>> things
>>>>>> out.
>>>>>>
>>>>>> Strange enough it turns out this problem is caused by disabling the
>>>>>> Nag
>>>>>> menu. I did so because we don't use Nag and we have to keep things
>>>>>> in the
>>>>>> UI as simple as possible over here. I disabled the Nag menu in
>>>>>> horde/config/registry.local.php like this:
>>>>>>
>>>>>>> /* disable nag
>>>>>>> 'nag' => array(
>>>>>>> 'name' => _("Tasks"),
>>>>>>> 'provides' => 'tasks',
>>>>>>> ),
>>>>>>>
>>>>>>> 'nag-menu' => array(
>>>>>>> 'status' => 'topbar',
>>>>>>> 'app' => 'nag',
>>>>>>> 'topbar_params' => array(
>>>>>>> 'id' => 'menu'
>>>>>>> ),
>>>>>>> 'menu_parent' => 'nag',
>>>>>>> ),
>>>>>>> */
>>>>>
>>>>> The correct way to disable Nag (see the comments in the header of
>>>>> 'horde/config/registry.php'), would be to put the following in
>>>>> 'horde/config/registry.local.php':
>>>>>
>>>>> <?php
>>>>> $this->applications['nag']['status'] = 'inactive';
>>>>>
>>>>>> This will remove the Nag menus allright but also seems to break
>>>>>> something
>>>>>> in Kronolith causing the timezone issue I described earlier.
>>>>>
>>>>> One lesson to learn, is that you should *never* redefine arrays in
>>>>> your *.local.php files. Instead, just change the parameter that
>>>>> you're interested in. This is documented in almost every
>>>>> configuration file (at the top), just not in this one.
>>>>
>>>> yes, I already found that out. Should start reading the manual before
>>>> and not afterwards. Lesson learned, thank you.
>>>>
>>>> However this is not the cause for my timezone issues. Disabling Nag
>>>> the correct way results in the same behaviour. I verified it on the
>>>> test machine:
>>>>
>>>> Corrected the bad registry.local.php, created a new registry.local.php
>>>> containing the correct code for setting Nag inactive.
>>>> Logged in, Nag inactive indeed.
>>>> Entered 2 new items in my calendar, both from 10-11, one with timezone
>>>> default and the other with timezone Europa/Amsterdam.
>>>> The one with tz default is displayed correctly, the one with tz E/A
>>>> appears from 8 to 9. This is happening with all items set to E/A,
>>>> including existing items. Perfectly reproducible.
>>>>
>>>> So setting Nag inactive appears to be the cause rather than disabling
>>>> Nag the wrong way. One way or another there must be some dependency
>>>> that is broken this way?
>>>>
>>>>>> Re-enabling the Nag menu on my test machine caused all start- and
>>>>>> ending
>>>>>> times of all calender items that were set to "default" timezone to
be
>>>>>> modified (2 hours later). So I'd rather not do that on my production
>>>>>> server...
>>>>>
>>>>> I'm afraid you'll have to bite the bullet here and fix this in the
>>>>> database.
>>>>
>>>> I know... should not be a major problem though. All it takes is adding
>>>> 2 hours to the times of any calendar items with the tz set to
>>>> Europe/Amsterdam, sure I can work out something clever to do that
>>>> automagically. But first I need to solve the initial problem.
>>>>
>>>>>> Would be very nice to have a better fix. Any suggestions welcome!
>>>>>>
>>>>>> thanks, Martin
>>>>>>
>>>>>> Citeren Systeembeheer BCS <adje at bezoekerscentrumsonsbeek.nl>:
>>>>>>
>>>>>>> We like the time of an event to appear in the different calendar
>>>>>>> views
>>>>>>> (Month, Week) so on the Calendar>User interface preference page we
>>>>>>> set
>>>>>>> "Choose the views to show event start and end times in:" to "Month,
>>>>>>> Week
>>>>>>> and Day Views". That works fine.
>>>>>>>
>>>>>>> Now when creating a new event in the calendar, some users change
the
>>>>>>> timezone in the event window from "Default" to "Europe/Amsterdam".
>>>>>>> That
>>>>>>> should not make a difference as Europe/Amsterdam is the default
>>>>>>> timezone
>>>>>>> anyway and all users are set to this. But it does make a
difference:
>>>>>>> - With the timezone of an event set to default, times displayed in
>>>>>>> the
>>>>>>> calendar views are correct.
>>>>>>> - Events with the timezone set to Europe/Amsterdam appear with the
>>>>>>> start- en ending times displayed with an offset of -2 hours.
>>>>>>>
>>>>>>> Running Horde Groupware 5.1.4, Kronolith version 4.1.5 on Ubuntu
>>>>>>> server
>>>>>>> 12.04LTS.
>>>>>>> /etc/timezone on the system is set to Europe/Amsterdam, the 'date'
>>>>>>> command shows the correct local time from the command line.
>>>>>>>
>>>>>>> Maybe related: although Ubuntu has the correct timezone setting, in
>>>>>>> Horde's "global prefs">"Locale and Time" setting all users have to
>>>>>>> set
>>>>>>> the default timezone to Europe/Amsterdam anyway to get the correct
>>>>>>> time
>>>>>>> in Horde. I assume Horde always references to UTC regardless of
>>>>>>> system
>>>>>>> settings?
>>>>>>>
>>>>>>> Thanks...Martin
>>>>>>
>>>>>>
>>>>>> --
>>>>>> kronolith mailing list
>>>>>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>>>>>> To unsubscribe, mail: kronolith-unsubscribe at lists.horde.org
>>>>>
>>>>> --
>>>>> This message was sent from a mailinglist subscription address.
>>>>> For off-list replies, you must remove the address extension.
>>>
>>> Still cannot reproduce this with Nag disabled.
>>
>> So I started out with a complete fresh horde install. Removed everything
>> according to instructions on http://wiki.horde.org/UninstallPEAR and
>> reinstalled horde. Set only basic configuration for accessing the
>> databases and left all other config files default.
>>
>> Logged in and entered 2 events in the calendar.
>> Event 1: from 10:00-11:00, timezone default.
>> Event 2: from 10:00-11:00, timezone Europe/Amsterdam
>> I checked the database table kronolith_events and both items were stored
>> in UTC times, so from 8:00-9:00. The timezone field for event 1 is empty
>> (''), for event 2 it is set at "Europe/Amsterdam". Both events displayed
>> correctly in the calendars.
>>
>> Next logged out, created a horde/config/registry.local.php containing
>
> only
>> <?php
>> $this->applications['nag']['status'] = 'inactive';
>>
>> Everything else left untouched. Logged back in, no Nag anymore.
>> Both event 1 and 2 are now displayed from 8:00 to 9:00 in the calendar
>> views.
>> When opening event 1 in the event editor, tz is default as set before
>> but times are now 8:00 to 9:00
>> When opening event 2 in the event editor, nothing has changed so tz is
>> E/A and times are 10:00 to 11:00
>>
>> Next I created 2 new events, same as before:
>> Event 3: from 10:00-11:00, timezone default.
>> Event 4: from 10:00-11:00, timezone Europe/Amsterdam
>>
>> Event 3 is shown correctly from 10-11 in the calendar views, but event 4
>> shows up from 8-9.
>> In the database, for event 3 times are set at 10:00 to 11:00 and tz at
>> ''. So different from event 1.
>> Event 4 times are set at 8:00 to 9:00 and tz = 'Europe/Amsterdam'. Same
>> as event 2.
>>
>> Upon re-opening the events both show the correct times (10:00 - 11:00)
>> in the event editor. While event 4 appears from 8-9 in the calendar
>> views.
>>
>> Timezone default for the user under Global Preferences > locale and time
>> was set at Europe/Amsterdam at all times. System timezone in
>> /etc/timezone was also set at Europe/Amsterdam.
>>
>> So the event editor seems to behave differently from the calendar views
>> with Nag disabled.
>>
>> With all other horde config files default, errors here can be probably
>> ruled out now.
>>
>> But since Jan Schneider can not reproduce it, the only thing I can thing
>> of is that some user settings in the database causes this. I re-used the
>> existing mail- and horde databases. Could this be a clue pointing in the
>> right direction?
>>
>>> --
>>> Jan Schneider
>>> The Horde Project
>>> http://www.horde.org/
>>> https://www.facebook.com/hordeproject
>>>
>>> --
>>> kronolith mailing list
>>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>>> To unsubscribe, mail: kronolith-unsubscribe at lists.horde.org
>>
>> --
>> kronolith mailing list
>> Frequently Asked Questions: http://wiki.horde.org/FAQTo unsubscribe,
>> mail: kronolith-unsubscribe at lists.horde.org
>
> --
> kronolith mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQTo unsubscribe,
> mail: kronolith-unsubscribe at lists.horde.org
More information about the kronolith
mailing list