Paul Eggert <eggert@twinsun.com> wrote:
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.
Many (most?) countries make a practice of announcing changes well in advance, and the overwhelming majority of time zone queries will concern times in those countries. Hence, an expiry period of fraction of the conventional period for such a country (e.g. a month) could radically reduce the TCP traffic for zone queries overall.
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).
Of course some countries do not make a practice of forewarning us, and the expiry period for their cached records could be as little as 24 hours. A policy with such a short expiry period would *still* radically reduce net traffic for queries against that record, compared to an "always check the authoritative network source" policy. In practice, times for places that change with such short notice have low reliability anyway, so there seems to me little danger in giving them what might seem an unreasonably long expiration time (e.g. a week). Anyway, the minimum expiry period of most current TZ installations is measured in years, so even with the occasional blip the aggregate reliability of the times produced would still be vastly improved over the status quo. Time zone conversions are never better than a "best guess" in any case, for the reasons Paul mentions.
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", the expiry period must be assumed to be short. In specific common important cases there is good reason to make it long. The longer it is, the quicker is the response time for users, and the lower is the overall network traffic load. [Perhaps the client should be allowed to specify how long it is willing to wait for a time zone conversion, so that if the network response is too slow the cache is used regardless of its expiry date. (The daemon should update the cache anyway, if it eventually succeeds.)] Nathan Myers ncm@cantrip.org