[kronolith] timezone problem in Calendar Views

[Systeembeheer BCS]

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.