Recurring events with timezone

[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.

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