[kronolith] timezone problem in Calendar Views
Systeembeheer BCS
adje at bezoekerscentrumsonsbeek.nl
Sun Jun 22 10:43:02 UTC 2014
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
More information about the kronolith
mailing list