- tz - lists.iana.org

net TZ access
by ncm＠cantrip.org Oct. 1, 1997

Oct. 1, 1997

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

3 2

time zone object
by ncm＠cantrip.org Sept. 30, 1997

Sept. 30, 1997

John Cowan <cowan(a)drv.cbc.com>: > I would like to point out that HTTP (both 1.0 and 1.1) > can send an "Expires:" header (in GMT) that communicates > to the client the server's notion of how long the object > is good for, exactly what we want. I propose that this > should *not* be stored in the "zoneinfo" file, because > its value should be a local decision, and "zoneinfo" > files ought to be the same everywhere (though some > will be out of date). How can files that are sometimes "out of date" be "the same everywhere"? Either they're *all* up-to-date, or some are not the same; you can't have both. Anyway, I don't see how a function looking up a time zone adjustment, and trying to decide whether to go out to the net for an update, can make that decision if the expiry time isn't stored anywhere. A site should have the option to disregard an expiry date; some sites may choose to lop off all predictions greater than seven days as too optimistic, and other sites to make the expiry date always at least seven days, to reduce traffic. This argues for an "expiration advisory" provided as part of the canonical distribution, and "expiration choice" that are by default the same, but may be different according to local preference. > I would also suggest that the next release of "zic" > incorporate a magic-number facility. To make a concrete > proposal, let us make the first four bytes equal to > "\0x14\0x1a\0x54\0x5a", or Ctrl+T, Ctrl+Z, T, Z. > This can then be incorporated into the Unix /etc/magic > file so that zoneinfo files can be described by the > "file" command. This I most emphatically agree with! There should also be a "format version" number. (Maybe it's there already.) Nathan Myers ncm(a)cantrip.org

1 0

Re: time zone object
by ncm＠cantrip.org Sept. 30, 1997

Sept. 30, 1997

John Cowan > Markus Kuhn wrote: > > Therefore, I consider anything less than 64-bit timestamps and > > nanosecond resolution in a new portable clock interface to be somewhat > > old-fashioned and ignorant about current hardware capabilities. > > And I consider a representation that is limited to the years > 1901 through 2038 rather short-sighted. It's clear that time_t, timespec, and the Java whatsit are not the final word on time/date representations. In C++, a TimeZone class could be a template that accepts any such representation, specialized for the ones actually used, and suffering limitations each imposes only when that one is used. What we need to work out is the interface for a class that computes adjustments to whatever representation is in use. This means (1) an infrastructure (protocols, conventions) to provide up-to-date zone information to programs that need it; and (2) a call interface that allows a reasonable person to write code that operates on wall-clock time with some hope of getting it right. As John Cowan pointed out, HTTP would suffice as a low-level protocol for access to zone tables across the net, but we also need to identify authoritative sources of up-to-date information; and 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. Does the "zic" format permit a datestamp? Nathan Myers ncm(a)cantrip.org

3 2

time zone object
by ncm＠cantrip.org Sept. 30, 1997

Sept. 30, 1997

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

2 1

RE: time zone object
by Olson, Arthur David Sept. 30, 1997

Sept. 30, 1997

As John Cowan pointed out, HTTP would suffice as a low-level protocol for access to zone tables across the net, but we also need to identify authoritative sources of up-to-date information; and 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. Does the "zic" format permit a datestamp? There are bytes "reserved for future use" at the front of the file. --ado

1 0

Re: time zone object
by ncm＠cantrip.org Sept. 29, 1997

Sept. 29, 1997

John Cowan <cowan(a)drv.cbc.com> > Nathan Myers wrote: > > a "double", relative to Jan 1, 2001, ... > > would give microsecond accuracy for now, with > > precision decreasing as we pass and recede from that date; or we > > could use a 64-bit integer count of microseconds from practically > > any choice of epochs. Each representation has its advantages. > > First, note that the term "epoch" refers to the moment of time > represented as zero, not the range of expressible times. The > Unix epoch is 1997 Jan 1 00:00:00 GMT. I believe I used the term "epoch" correctly. Of course (as I said) the choice of epoch is of no interest given a fixed-precision time value. A floating-point time has greatest precision near the epoch. With a 48 bit mantissa, precision would still be better than a millisecond for dates throughout recorded history. > ... I favor the Java convention: a 64-bit signed integer > representing milliseconds, with the same epoch as Unix. That > provides sufficient resolution for normal purposes (anything > that *requires* microsecond resolution probably requires > microcode, embedded programming, or the like), and has a range > clear back to the Carboniferous Period (~300 My B.P.) Some of us do write microcode and embedded programs, and code in such environments tends make more use of time quantities than the is conventional (hence the term "real-time"). Still, the current Java convention seems tolerable for most uses. > > The second familiar problem is the crossover periods for time changes. > > Converting from microseconds-past-epoch to local time is well-defined; > > but conversion back demands accommodation to local time that doesn't > > exist (during "spring forward" gaps); and [2] local time that is > > ambiguous (before or after "fall back"). Since there isn't any really > > satisfactory solution to these, they just need to be visible (and > > unavoidable) in the interface. > > The ADO package uses the is_dst field to resolve the ambiguity. > Except during "fall back" overlaps, this field isn't required when > converting from broken-out local time to absolute time, but it is > used to resolve the ambiguity in that case. The is_dst field fails to solve the problem. The problem is that the caller of the conversion function is generally not equipped to "resolve the ambiguity", or even to determine whether there is an ambiguity to resolve. The overwhelming majority of programs do not (and probably cannot) correctly or meaningfully use the is_dst field. The conversion function itself can tell whether there might be an ambiguity, but has no way to communicate it back to the caller, or to identify the set of alternatives. I believe that the conversion function must return a value that represents 0, 1, or 2 time values, so that the caller is equipped to (and forced to) deal with the ambiguity after all the necessary information is available. We also need a time representation equivalent to "NaN" that permits us to talk about times shortly before the epoch. > > The third problem is that the TZ database on line is available only > > in a form that would be very clumsy to handle in an on-line transaction. > > That is, if it changes at all (which happens frequently), there is no > > way to check for rule changes in a particular locality without downloading > > the whole thing and unpacking it, which would introduce an unacceptable > > delay in an interactive application. > > Why so? A server can load single "zoneinfo" binary files as needed > from a conventional HTTP server: several could be provided around > the Internet, and intranets could have one or two available also. This seems like the beginning of a reasonable approach. Better failure tolerance than "Error 200" seems needed. Nathan Myers ncm(a)cantrip.org

3 2

time zone object
by ncm＠cantrip.org Sept. 26, 1997

Sept. 26, 1997

On Wed, 24 Sep 1997, John Cowan wrote: > I would be interested in hearing from people > who want to help improve the currently rather feeble Java 1.1 > implementation of time zones. Jeffrey Sean Connell wrote: > This couldn't possibly have come at a better time. I agree, this would be the proverbial Good Thing. I need a a similar interface for a C++ locale facet. If the level of traffic gets too great for this mailing list, we can take it off-line. I see several problems in current implementations that I would not want to propagate into an object interface. First, a 32-bit epoch would be a big mistake; we can use a "double", relative to Jan 1, 2001, which would give microsecond accuracy for now, with precision decreasing as we pass and recede from that date; or we could use a 64-bit integer count of microseconds from practically any choice of epochs. Each representation has its advantages. The second familiar problem is the crossover periods for time changes. Converting from microseconds-past-epoch to local time is well-defined; but conversion back demands accommodation to local time that doesn't exist (during "spring forward" gaps); and [2] local time that is ambiguous (before or after "fall back"). Since there isn't any really satisfactory solution to these, they just need to be visible (and unavoidable) in the interface. The third problem is that the TZ database on line is available only in a form that would be very clumsy to handle in an on-line transaction. That is, if it changes at all (which happens frequently), there is no way to check for rule changes in a particular locality without downloading the whole thing and unpacking it, which would introduce an unacceptable delay in an interactive application. To check only locally depends on "system administrators" to install updates, but most Java platforms will have (for practical purposes) no system administrator. One solution would be a network of TZ servers that can hand out up-to-date fragments of the database on demand, similar to DNS service. A good time zone class would adapt to different sources of zone information in much the way IP name lookup happens, but with fallback to a local cache when the network is inaccessible. Probably the IETF should be involved in this last bit ... do any IETF members monitor this list? Nathan Myers ncm(a)cantrip.org http://www.cantrip.org/

4 3

FW: South Africa
by Olson, Arthur David Sept. 25, 1997

Sept. 25, 1997

I don't know the basis of the "official abbreviaton" phrase in Mark's letter. --ado ---------- From: Mark R V Murray[SMTP:markm@iafrica.com] Sent: Thursday, September 25, 1997 1:49 PM To: tz(a)elsie.nci.nih.gov Hi In your timezone info for Africa, you have "invented" SAT for South African Time. Please will you change this to the official abbreviation of SAST for South African Standard Time. Countries outside South africa use the CAT, EAT, WAT etc names. Thanks! M -- Mark Murray Senior Network Engineer, UUNET Internet Africa Join the anti-SPAM movement: http://www.cauce.org

1 0

None
by Mark R V Murray Sept. 25, 1997

Sept. 25, 1997

Hi In your timezone info for Africa, you have "invented" SAT for South African Time. Please will you change this to the official abbreviation of SAST for South African Standard Time. Countries outside South africa use the CAT, EAT, WAT etc names. Thanks! M -- Mark Murray Senior Network Engineer, UUNET Internet Africa Join the anti-SPAM movement: http://www.cauce.org

1 0

Java class ADOTimeZone
by John Cowan Sept. 25, 1997

Sept. 25, 1997

I am in the process of implementing a Java 1.1 class called "ADOTimeZone" which provides support for the ADO timezone information. The different zones, compiled on a Unix system, are being included with the Java class as class-specific resources. Currently I have compilable code, but I have not yet begun component testing. When the code works, I will be giving it away freely. I would be interested in hearing from people who want to help improve the currently rather feeble Java 1.1 implementation of time zones. -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org e'osai ko sarji la lojban

2 1