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
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. 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! Not only would there be political problems with this rule of thumb, technically speaking it's not very accurate. The USA, for example, has historically been much less stable time-zone-wise than the Dem. Rep. of Congo, which hasn't futzed with its clocks for nearly a century. 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. 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. 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. By comparison, SNTP sends packets every 64 s to every 1024 s, depending on configuration. If this overhead is acceptable, then a packet every day extra will be in the noise. 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.
participants (2)
-
ncm＠cantrip.org -
Paul Eggert