Recurring events with timezone
Hendrik Helwich
h.helwich at tarent.de
Tue Oct 19 13:26:33 CEST 2010
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
More information about the format
mailing list