<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Am 20.10.2010 08:46, schrieb Joon Radley:
<blockquote
cite="mid:3853C16E-95E7-4C7E-AE59-E368923269AD@radleys.co.za"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
Hi Joon,<br>
<br>
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.<br>
<br>
Greetings,<br>
<br>
Hendrik<br>
<br>
<br>
<blockquote
cite="mid:3853C16E-95E7-4C7E-AE59-E368923269AD@radleys.co.za"
type="cite">
<pre wrap="">
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: <a class="moz-txt-link-abbreviated" href="mailto:support@toltec.co.za">support@toltec.co.za</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.toltec.co.za">www.toltec.co.za</a>
On 15 Dec 2010, at 1:26 PM, Hendrik Helwich wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am 19.10.2010 10:08, schrieb Joon Radley:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:Kolab-format@kolab.org">Kolab-format@kolab.org</a>
<a class="moz-txt-link-freetext" href="https://kolab.org/mailman/listinfo/kolab-format">https://kolab.org/mailman/listinfo/kolab-format</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Kolab-format mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kolab-format@kolab.org">Kolab-format@kolab.org</a>
<a class="moz-txt-link-freetext" href="https://kolab.org/mailman/listinfo/kolab-format">https://kolab.org/mailman/listinfo/kolab-format</a>
</pre>
</blockquote>
<br>
</body>
</html>