Timezone issues

Martin Konold konold at erfrakon.de
Tue Jun 3 00:28:07 CEST 2008


Hi Bernhard,

>> When entering a date e.g. for an event KDE Kontact should use
>>
>> <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
>> Wien</time-zone>
>
> what do you mean by "entering" a date?

I mean creating an event with the KDE Kontact (KOrganizer) UI.

> (I've just tried Kontact 1.2.9 (enterprise 20080520.810305)
> and created an event and looked at the resultung Kolab-xml file,
> there is no <time-zone> tag in there.)

This is the report from a user on Debian stable:

User-Agent: KONSEC Konnektor 1.1.8.1
X-KONN-ENTRYID: 000000002E364946FA823D4CB5A733B3C3E57C5EA4932000
X-KONN-IMPORTANCE: 1
X-KONN-SENSITIVITY: 0
X-Kolab-Type: application/x-vnd.kolab.event
X-MS-TNEF-Correlator: 000000002E364946FA823D4CB5A733B3C3E57C5EA4932000
Mime-Version: 1.0
From: Some Testuser <test.user at xxxx.bund.de>[D
Subject: 93F8AC566C3DE8419DC85BF1B9825F60
Date: Tue, 13 May 2008 16:19:12 +0200   <--------------here correct !
X-KONN_CLIENT_SUBMIT: Tue, 13 May 2008 16:19:12 +0200
Message-ID: <4829A360.000001.00798 at unknown.host>
Content-Type: Multipart/Mixed;
   boundary="------------Boundary-00=_049TrDhZwyzf3w8CRv6t"

--------------Boundary-00=_049TrDhZwyzf3w8CRv6t
Content-Type: Text/Plain; charset=
Content-Transfer-Encoding: base64


--------------Boundary-00=_049TrDhZwyzf3w8CRv6t
Content-Transfer-Encoding: quoted-printable
Content-Type: application/x-vnd.kolab.event; name=event.xml
Content-Disposition: attachment; filename=event.xml

<?xml version=3D=221.0=22 encoding=3D=22UTF-8=22?>
<event version=3D=221.0=22>
   <product-id>KONSEC Konnektor 1.1.8.1 Build: Mar 17 2008</product-id>
   <netmeeting-type>0</netmeeting-type>
   <is-all-day-event>0</is-all-day-event>
   <show-time-as>busy</show-time-as>
   <meeting-status>0</meeting-status>
   <duration>30</duration>
   <response-status>0</response-status>
   <recurrence-type>0</recurrence-type>
   <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, 
Wien</time-zone> <-------- this does correctly not reflect DST
   <is-recurring>0</is-recurring>
   <conference-server-allow-external>1</conference-server-allow-external>
   <cal-unknown-0x8124>0</cal-unknown-0x8124>
   <cal-unknown-0x8224>-1</cal-unknown-0x8224>
   <cal-unknown-0x8256>0</cal-unknown-0x8256>
   <cal-unknown-0x8207>0</cal-unknown-0x8207>
   <cal-unknown-0x8257>0</cal-unknown-0x8257>
   <cal-unknown-0x8259>0</cal-unknown-0x8259>
   <cal-unknown-0x825a>0</cal-unknown-0x825a>
   <cal-unknown-0x8235>2008-05-13T16:00:00Z</cal-unknown-0x8235>
   <cal-unknown-0x8236>2008-05-13T16:30:00Z</cal-unknown-0x8236>
   <cal-unknown-0x8245>0</cal-unknown-0x8245>
   <cal-unknown-0x8201>0</cal-unknown-0x8201>
   <unknown-0x8510>369</unknown-0x8510>
   <unknown-0x8518>0</unknown-0x8518>
   <priority>0</priority>
   <sensitivity>public</sensitivity>
   <private>0</private>
   <summary>Test-Zeitverschiebung bei Terminen-aap</summary>
   <creation-date>2008-05-13T14:18:50Z</creation-date>
   <last-modification-date>2008-05-13T14:18:50Z</last-modification-date>

This means that in this case the <time-zone> tag was added by the KONSEC 
Konnektor. According to the Debian user this event is off-by-one hour in 
KDE Kontact.

>> Rational: The timezone is solely dependend on the geographic location but
>> not on the week. This is especially important for events spanning over DST
>> switching sundays.
>
> Well, both variants do not seem to be a nice specification of a time-zone,
> they both are wrong about half of the year.

I tend to disagree with this statement. IMHO the location Berlin is always 
GMT+1 independent of DST. In general DST does NOT affect the timezone. The 
later is only affected by the location.

> Currently we do not have "time-zone" in the specification.
> Are you proposing to add it?

Yes. I propose to add <time-zone> to the specification and explicitly 
stating the the adaption according to the DST has always to be handled in 
the client while displaying not while storing.

> (I would welcome this as I believe that there is a rare problem
> when specifying recurrent events, which we discussed years ago.)

Why is a recurring event like weekly on Mondays at 2pm a rare use case?

>> E.g. a daily recurring event at 12 noon like "lunch" shall always happen at
>> the same time and not be affected by daylight saving time switches.
>
> Correct means it should happen on the same time within the time zone,
> so in summer time it is always 12:00 (even when this is 11:00 or 10:00 UTC
> depending on the daylight saving period it occurs in).

Yes, and therefore the time stored permanently must be independent on DST 
but dependent on explicit timezone.

This is the only safe way to store an event like 12 noon at some 
future date because DST rules are due to political reasons unpredictable (only 
guessable).

>> BTW: This is something which MS Outlook 2K3 does correct ;-)
>
> I believe Kontact does this correctly, though.
> If not please let us know the test case or directly file an issue
> in the tracker.

The above mentioned customer claims that KDE Kontact in Debian stable 
shifts the event by one hour in case the event got created with KONSEC Konnektor.

Regards,
-- martin




More information about the format mailing list