<!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 10:30, schrieb Joon Radley:
<blockquote
 cite="mid:C038CF5E-A89F-4B13-9818-A94CF2EE1A33@radleys.co.za"
 type="cite">
  <pre wrap="">Hi Hendrik,

  </pre>
  <blockquote type="cite">
    <pre wrap="">
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
    </pre>
  </blockquote>
  <pre wrap="">
Now lets turn this around, you create the event in Johannesburg and accordingly include the CAT time zone:

How will you now do the conversion for the German user with only the Johannesburg Time Zone information?
  </pre>
</blockquote>
<br>
You mean if the meeting should happen in Johannesburg? Its just
similar. Add the local timezone to the kolab xml:<br>
<br>
<pre><?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>Africa/Johannesburg</id>
        <standard-time name="SAST">
                <offset>+0200</offset>
        </standard-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></pre>
Then the meeting start time would be always at 10 o'clock in
Johannesburg.<br>
If a person in germany would see this event it would be converted like
this:<br>
<pre>
In october:
south africa 10 -> UTC 8 -> german local 10
in november:
south africa 10 -> UTC 8 -> german local 9</pre>
<br>
Greets,<br>
Hendrik<br>
<br>
<blockquote
 cite="mid:C038CF5E-A89F-4B13-9818-A94CF2EE1A33@radleys.co.za"
 type="cite">
  <pre wrap=""> 
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 20 Oct 2010, at 9:34 AM, Hendrik Helwich wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Am 20.10.2010 08:46, schrieb Joon Radley:
    </pre>
    <blockquote 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.

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?
  
      </pre>
    </blockquote>
    <pre wrap="">
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

    </pre>
    <blockquote type="cite">
      <pre wrap="">[..]
  
      </pre>
    </blockquote>
    <pre wrap="">
_______________________________________________
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>