From: Paul Eggert <eggert@twinsun.com>:
Date: Mon, 29 Sep 1997 20:25:55 -0700 (PDT) From: ncm@cantrip.org (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@cantrip.org