Re: timezone problem in Calendar Views

  Citeren Jan Schneider <[email protected]>:

> Zitat von Systeembeheer BCS <[email protected]>:
>
>> Citeren Arjen de Korte <[email protected]>:
>>
>>> Citeren Systeembeheer BCS <[email protected]>:
>>>
>>>> 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 <[email protected]>:
>>>>
>>>>> 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: [email protected]
>>>
>>> --
>>> 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.

Thanks, confirms at least this is not normal behaviour or a bug. Must  
be something somewhere else in my configs messed up.
I will try comparing all config files with the originals and hope I  
find something interesting.

Thanks for looking into it and reporting back


>  
> --
> Jan Schneider
> The Horde Project
> http://www.horde.org/
> https://www.facebook.com/hordeproject
>
> --
> kronolith mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQTo unsubscribe,
> mail: [email protected]

-- 
kronolith mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]