John Cowan
Markus Kuhn wrote:
Therefore, I consider anything less than 64-bit timestamps and nanosecond resolution in a new portable clock interface to be somewhat old-fashioned and ignorant about current hardware capabilities.
And I consider a representation that is limited to the years 1901 through 2038 rather short-sighted.
It's clear that time_t, timespec, and the Java whatsit are not the final word on time/date representations. In C++, a TimeZone class could be a template that accepts any such representation, specialized for the ones actually used, and suffering limitations each imposes only when that one is used. What we need to work out is the interface for a class that computes adjustments to whatever representation is in use. This means (1) an infrastructure (protocols, conventions) to provide up-to-date zone information to programs that need it; and (2) a call interface that allows a reasonable person to write code that operates on wall-clock time with some hope of getting it right. As John Cowan pointed out, HTTP would suffice as a low-level protocol for access to zone tables across the net, but we also need to identify authoritative sources of up-to-date information; and specify caching of retrieved information with preference for the cached data up to an expiry date. This requires representing the expiry date in the cached file. Does the "zic" format permit a datestamp? Nathan Myers ncm@cantrip.org
Date: Mon, 29 Sep 1997 16:59:50 -0700 (PDT) From: ncm@cantrip.org (Nathan Myers) we also need to ... specify caching of retrieved information with preference for the cached data up to an expiry date. This requires representing the expiry date in the cached file. I don't think it's realistic to insist on an expiry date for time zone rules. In practice, these rules can change with very little notice. For example, last year the Sri Lankan government gave less than 24 hours' notice of an emergency rule change that moved the clocks ahead by an hour. See ``Sri Lanka advances clock by an hour to avoid blackout'', http://www.virtual-pc.com/lankaweb/news/items/240596-2.html (1996-05-24). 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.
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
participants (3)
-
Markus Kuhn -
ncm＠cantrip.org -
Paul Eggert