Recurring events with timezone

Hendrik Helwich h.helwich at tarent.de
Wed Oct 20 10:06:22 CEST 2010


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
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20101020/c081b9eb/attachment.html>


More information about the format mailing list