Re: timezone problem in Calendar Views

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.

-- 
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: [email protected]