time zone object

[Markus Kuhn]

> In general, time zone rules are ``until further notice'',
> and any automated system for propagating time zone rules
> will just have to take this into account.

Well, with for instance the EU rules, we have in the law defined for how long
the current rules are guaranteed to last. This knowledge is useful for
a time zone handling system if redundant information about the time
zone is available, in order to adjust the priorities of the redundant 
information according to the expire date and in order to decide when to
bother the user with warning messages.

For instance, in the Newman draft for future dates, we have both a tz name
like Europe/Berlin and a numeric offset like +02. If the receiving system
has a rule for Europe/Berlin, then it should apply it if the rule has not yet
expired. If the rule has expired and what the rule says contradicts the 
given numeric offset, then the user should be informed in a warning about
the problem that there might be a missunderstanding regarding the
time zones on the two communicating systems.

This leads me to a new suggestion: The numeric offset in the Newman
draft should be extended by a "?" flag that indicates whether the given
future time is AFTER the expire time of the time zone rule as known by the
sending system. For instance

  2010-09-30 15:00 Europe/Paris +02?

means that the sending system assumes that France will still be in
UTC+02h at this time, but it is not sure since the EU directive it knows goes
only until 2004. If the receiving system has a later expire time (due to
updated tables), it can due to the ? found after the offset silently
override the numeric offset and has not to bother the user with a warning
just because the sending side has old tables.

(All this is said with the distributed calendar applications in mind.
I am not sure however whether it is reasonable to build that sophisticated
mechanisms to handle the uncertainties of future local time stamps,
or whether this just leads to annoying software that causes problems by
trying to be too smart.)

Markus

-- 
Dipl.-Inf. Markus Kuhn, Schlehenweg 9, D-91080 Uttenreuth, Germany
mkuhn at acm.org, http://wwwcip.informatik.uni-erlangen.de/~mskuhn