konold at erfrakon.de
Tue Jun 3 00:28:07 CEST 2008
>> When entering a date e.g. for an event KDE Kontact should use
>> <time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
> 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 18.104.22.168
From: Some Testuser <test.user at xxxx.bund.de>[D
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: Text/Plain; charset=
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?>
<product-id>KONSEC Konnektor 22.214.171.124 Build: Mar 17 2008</product-id>
<time-zone>(GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm,
Wien</time-zone> <-------- this does correctly not reflect DST
<summary>Test-Zeitverschiebung bei Terminen-aap</summary>
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
>> 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
>> 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.
More information about the format