Timezone issues
Alan J Collison
alan at collison.net
Tue Jun 3 17:23:52 CEST 2008
A few comments:
1. It appears that the event shown below is not recurring. In that case,
time zone is irrelevant. The start date-time in UTC
uniquely identifies when the event begins - i.e.,
given whatever time zone you choose, you can derive
the start time of the event given it's start time in UTC.
So for this event, storing time zone information
is entirely unnecessary. Time zone info is important for
recurring events, not for non-recurring events.
2. Probably just an issue of semantics, but DST does not change
your time zone - it changes your offset from GMT. My time
zone designation is America/New_York, the Olson designation for
the US East coast. After a DST change, I'm still in the
America/New_York time zone :)
I can determine my current offset from the time zone information
contained in my systems TZ data (which I believe for most, if not
all, systems is based on the Olson DB nowadays).
3. For recurring events you *must* include time zone information for
the time zone the event was created in,
otherwise you're just saying "well, it will work *most* of the
time." If that's what you're shooting for then I guess that's
fine, but the cases where this will fail without specifying
time zone are more common than you might think and can
change over time. As Martin noted, DST is a political thing and
any locale can decide to observe it or not and arbitrarily decide
how much to shift. In the U.S., there are specific regions
where the local governments decided to not observe DST even though
most of the country does - and, at least one locale I know of
changed just this past year.
4. I do not see why you need to alter the datetime definition.
datetime is always UTC, correct? Just add the <time-zone/>
tag and for God's sake use the Olson time zone designations :)
It's true that iCalendar would allow the flexibility to
specify different time zones for each date-time value, but in practice
I have never seen any client do this. Unlike DST, ignoring
that possibility is a much safer bet. Given the start time in
UTC and the time zone designation for the event, then any client can
determine the complete set of occurrences for the event
regardless of what time zone it is viewed in (assuming, of course,
the system the client is on has complete and updated
TZ data).
Any client which does not recognize the <time-zone/>
tag is no worse off than it currently is I think. For clients
that want to support this, they simply have to map whatever
client TZ designations it has to the Olson designations (preferably).
Some documents here may be of interest:
http://www.calconnect.org/recommendations.shtml
Alan
---- Bernhard Reiter <bernhard at intevation.de> wrote:
>
> Hi Martin,
>
> 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 1.1.8.1
>
> > 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.
>
> 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:
>
> http://en.wikipedia.org/wiki/Daylight_saving_time#Observance_practices
> 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.
>
> http://de.wikipedia.org/wiki/Zeitzone#Sommerzeit
> 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,
> UTC+2h).
>
> 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
> > Konnektor.
>
> 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.)
>
> Best,
> Bernhard
> --
> 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
>
More information about the format
mailing list