time zone object

[Nathan Myers]

Paul Eggert <eggert at twinsun.com> wrote:
>    From: ncm at 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 at cantrip.org