net TZ access

Nathan Myers ncm at
Tue Sep 30 18:34:32 UTC 1997

From: Paul Eggert <eggert at>:
>    Date: Mon, 29 Sep 1997 20:25:55 -0700 (PDT)
>    From: ncm at (Nathan Myers)
>    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.
> Yes, but there's no way to know which countries those are in advance.
> If you had asked me two years ago what the expiry time for Sri Lanka
> should be, I'd have suggested that it would be a very long time, as
> Sri Lanka hadn't futzed with their clocks at all since 1945.  But when
> their energy crisis hit critical mass last year, boom!  The clocks got
> changed.

We're not obliged to predict; some governments do it for us.  (Even the 
British Admiralty used to give a couple of months' warning.)  If we throw 
away that information, efficiency suffers accordingly.

> And surely you're not proposing a database with 0.5-day expiries for
> poorer countries' time zone rules, and 12-day expiries for richer
> countries', on the theory that the richer countries need the
> efficiency more!

Please, I said not one word about rich countries or poor countries.  
(A poor country, if anyone, has greater absolute need for efficiency.)

>    Hence, an expiry period of a fraction of the conventional period
>    for such a country (e.g. a month) could radically reduce the TCP
>    traffic for zone queries overall.
> Other solutions would reduce the IP traffic even further.  For
> example, the time zone server could notify the clients of changes
> instead of requiring the clients to poll the server.  This could be
> done via multicast to cut down on packet transmission even further.

A "push" policy (with attendant daemons, subcriptions, etc) would be 
a hard sell for something like time zone information that changes so 
infrequently, and has such a low perception of importance among those 
not subscribed to this list.

> If you're stuck with a protocol in which the client must poll the
> server, then probably the best you can do is have the clients poll
> once after each reboot or reconnect, and also once a day at a random
> time.  One packet-exchange per day should be acceptable overhead for
> almost all applications.

If a 24-hour expiry time were the default for zone entries, the result 
would be about the same, with less infrastructure. 

Introducing an expiry period of months for EU entries, based on their 
stated policy, would then mainly reduce such traffic in the EU, mainly 
to EU members' benefit.  Any country, rich or poor, can have a prior
notification policy, and do the same.
>    Anyway, the minimum expiry period of most current TZ installations
>    is measured in years ...
> I still think you're being too optimistic here.  Yes, most countries
> have had relatively stable time zone rules during the last decade or
> two.  But come the next war or energy crisis, and the rules will
> change again with very little notice.

My remark said nothing the stability of anybody's rules.  The point was 
that for all but a tiny handful of sites, neither the database nor the 
code is updated except when the OS itself is reloaded, which happens at 
intervals measured, on average, in years.  Hence, an expiry period of
a month for all entries would still give far, far more accurate results,
on average, than what is in common use now.

In other words, a program that took two weeks to get up-to-date on the 
sudden Sri Lankan time change would not be thought ill of, considering 
that most machines on the net *still* haven't got the change.

Nathan Myers
ncm at

More information about the tz mailing list