Recurring events with timezone
Hendrik Helwich
h.helwich at tarent.de
Wed Oct 20 09:34:07 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.
>
> 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?
>
Hi Joon,
timzones are working fine on my OS :-) the UTC time can surely be used
for single events/tasks. But it is possible to code recurring events in
kolab so you must add timezones to the format even if they are complex.
This is obvious i think. Otherwise it is not possible to fix this problem.
To the example:
The correct way would be to make the kolab xml with timezone e.g. like this:
<?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-19T10:00:00</start-date>
<summary>Test</summary>
<timezone>
<id>Europe/Berlin</id>
<standard-time name="CET">
<offset>+0100</offset>
</standard-time>
<daylight-saving-time name="CEST">
<offset>+0200</offset>
<start-date>
<month>march</month>
<day count="-1">sunday</day>
</start-date>
<end-date>
<month>october</month>
<day count="-1">sunday</day>
</end-date>
</daylight-saving-time>
</timezone>
<recurrence cycle="monthly" type="daynumber">
<interval>1</interval>
<daynumber>19</daynumber>
<range type="none"></range>
</recurrence>
<end-date>2010-10-19T12:00:00</end-date>
</event>
(I added the timezone block and changed start-date and end-date to the
local times)
My Kontact now can see that i am in the same time zone as it is stored
in the event and does not need to convert the local times. It can show
me the 10 o'clock start-time for all the year. It also can do the stored
local -> UTC -> local conversion but this would be an identity function
and will cause the same result.
If i am in Johannesburg my Kontact can convert each start-time to the
UTC time by using the stored time zone from germany and then convert it
to the system local time.
In october:
german local 10 -> UTC 8 -> south africa local 10
in november:
german local 10 -> UTC 9 -> south africa local 11
So this example could be calculated correctly. Without storing the time
zone information of germany that could not be possible.
Greetings
Hendrik
> [..]
>
More information about the format
mailing list