Recurring events with timezone

Joon Radley joon at radleys.co.za
Wed Oct 20 10:47:55 CEST 2010


Hi Hendrik,

> i am not sure if i understood this. The time zone information must be selectable by the kolab client to define in which time zone the meeting should happen. So a user in the Johanesburg time zone could also create a meeting which should happen in the german time zone. So the kolab xml would store the german time zone in this case.

Will UTC be different if you change the "time zone" when the event will take place? If you just want to keep a note for what time zone the user create the event, created a custom field to keep that information, but it does not impact on the validity of using UTC.

Best Regards

Joon Radley

Cell: +27 (0)83 368 8557
Fax: +27 (0)86 547 2353
E-mail: support at toltec.co.za
Web: www.toltec.co.za



On 20 Oct 2010, at 10:06 AM, Hendrik Helwich wrote:

> Am 20.10.2010 08:46, schrieb Joon Radley:
>> Hi Hendrik,
>> 
>> This is an excellent example. Your argument is that the incorrect conversion in the client of UTC -> local time can be fixed by adding time zone information to the object.
>> 
>> Lets run a use case with this. User A is the creator of the object and is situated in Johannesburg. User B that shares the folder is situated in Germany (for the daylight savings time).
>> 
>> The problem is: UTC -> User B local time is incorrect.
>> 
>> Your suggested solution is: User A Time Zone + User A Local Time -> UTC -> User B local time
>> 
>> UTC -> User B local time conversion will still be broken, as you need User B TZ to fix the incorrect calculation. Thus by adding the User A TZ information to the object no problem is solved.
>> 
>> The only time when the TZ information will help is when User A and User B is in the same time zone and they both know it. All other user cases do not benefit from User A’s TZ information.
>>   
>> 
> 
> Hi Joon,
> 
> i am not sure if i understood this. The time zone information must be selectable by the kolab client to define in which time zone the meeting should happen. So a user in the Johanesburg time zone could also create a meeting which should happen in the german time zone. So the kolab xml would store the german time zone in this case.
> 
> Greetings,
> 
> Hendrik
> 
> 
>> You are trying to fix a client “bug” by providing it with information, which will only be valid/helpful in very limited cases.
>> 
>> By fixing the UTC-> locale conversion you will fix all the use cases. The localtime function has never failed me. Is there a problem with it on your OS?
>> 
>> Best Regards
>> 
>> Joon Radley
>> 
>> Cell: +27 (0)83 368 8557
>> Fax: +27 (0)86 547 2353
>> E-mail: 
>> support at toltec.co.za
>> 
>> Web: 
>> www.toltec.co.za
>> 
>> 
>> 
>> 
>> On 15 Dec 2010, at 1:26 PM, Hendrik Helwich wrote:
>> 
>>   
>> 
>>> Am 19.10.2010 10:08, schrieb Joon Radley:
>>>     
>>> 
>>>> Could you please give an example of the bug that needs to be fixed?
>>>> 
>>>> Could you please explain how converting from locale ->  UTC ->  locale is better than just converting from UTC ->  locale?
>>>> 
>>>>       
>>>> 
>>> Hi Joon,
>>> 
>>> ok a small example: Assume i am in the german time zone (UTC+2 in summer 
>>> and UTC+1 in winter) and want to start from today a monthly infinitely 
>>> recurring event from 10-12 o'clock.
>>> Kontact creates a the following xml (i removed some tags):
>>> 
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <event version="1.0" >
>>> <product-id>KOrganizer 3.5.9 (enterprise35 20100805.1161816), Kolab 
>>> resource</product-id>
>>> <uid>libkcal-2077575338.372</uid>
>>> <sensitivity>public</sensitivity>
>>> <start-date>2010-10-19T08:00:00Z</start-date>
>>> <summary>Test</summary>
>>> <recurrence cycle="monthly" type="daynumber" >
>>> <interval>1</interval>
>>> <daynumber>19</daynumber>
>>> <range type="none" ></range>
>>> </recurrence>
>>> <end-date>2010-10-19T10:00:00Z</end-date>
>>> </event>
>>> 
>>> Kontact now shows this event starting at 10 o'clock also in november of 
>>> this year. But there is a different time offset in germany in november 
>>> so it should be shown at 9 o'clock instead if a correct UTC -> local 
>>> conversion would be made here. It seems kontact is doing a UTC -> local 
>>> on the start date of the event and assuming that the time offset does 
>>> not change. So in november kontact shows that this event will start at 9 
>>> o'clock UTC time.
>>> 
>>> But it gets more bad if i am in a different time zone now. Say i am an 
>>> attendee of this event and i live in Johannesburg in South Africa. The 
>>> time offset there is UTC+2 all the year. If i switch my computer and 
>>> Kontact to this time zone, Kontact also shows the start time at 10 
>>> o'clock all the year. This means in november of this year the person 
>>> from Johannesburg would be an hour to early at this meeting because the 
>>> UTC time would be 8 o'clock there (at least in this case he will not 
>>> miss it :-)  ).
>>> 
>>> This is an example of a problem that cannot be solved correctly without 
>>> adding time zone information to the storage format.
>>> 
>>> Greets,
>>> Hendrik
>>> 
>>> _______________________________________________
>>> Kolab-format mailing list
>>> 
>>> Kolab-format at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-format
>>> 
>>>     
>>> 
>>   
>> 
>> _______________________________________________
>> Kolab-format mailing list
>> 
>> Kolab-format at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-format
>> 
>>   
>> 
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format




More information about the format mailing list