bernhard at intevation.de
Tue Jun 3 16:09:57 CEST 2008
On Tuesday 03 June 2008 00:28, Martin Konold wrote:
> >> 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:
Which version of Kontact?
E.g. current and recommended is enterprise35 for Debian Etch.
> User-Agent: KONSEC Konnektor 188.8.131.52
> 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 184.108.40.206 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
Did you miss copying the <start-date>?
> According to the Debian user this event is off-by-one hour in KDE Kontact.
It is hard to judge without the <start-date> line. :)
A common mistake in Kontact configuration is that Settings -> Events ->
Date/Time is not set to the right timezone.
> >> 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.
Common explanations tend to differ from your view:
In this example, a location observing UTC+10 during standard time is at
UTC+11 during DST; conversely, a location at UTC−10 during standard time is
at UTC−9 during DST.
Viele Länder wechseln in der Frühlingsmitte in eine andere Zeitzone, im
Herbst wieder zurück. So gilt in den meisten EU-Staaten im Winter die MEZ
(UTC+1h), in den Sommermonaten aber die mitteleuropäische Sommerzeit (MESZ,
Roughly translated: Many countries switch into a different timezone mid spring
and back in the fall. So for most EU-countries it is MEZ (UTC+1h) in the
winter and middleeuropean sommertime in the sommer (MESZ UTC+1h).
> > 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.
We would need to change the datetime definition then to include timezone
information and we would need to come up with a good definition for timezone.
As this forces a massive change on all clients, I believe we should propose
something for beyond the 2.0 spec, which is stable as it is (and having the
shortcomings that is has).
> > (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?
Well, it is not. But people argued somehow that this was not happening
due to calculations when the appointment was made.
This reduced the problem to cases where you would do calculations on the
server with the clients having strange different daylightsaving time borders.
Making it a rare case.
I remembered testing this stuff Toltec and Kontact back and forth
and it used to work.
> >> 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.
You must know if daylight saving is used, yes.
If you make "Berlin" the name of that zone including daylight saving,
the "GMT+1" should be left out as it is wrong. Berlin will have GMT+1 and
GMT+2 depending on the DST. I think Unix's TZ= works like this.
> 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 claim that the GMT+1 is clearly false for Berlin in the summer.
> > 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
This is seems a special case we might want to continue discussing on the users
list. (To comment someone would need the Kontact version, the original
<start-date> tag and the korganiserrc setting for timezone.)
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the format