Date: Thu, 25 Sep 1997 11:50:57 -0700 (PDT) From: ncm@cantrip.org (Nathan Myers) 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.... Probably the IETF should be involved in this last bit ... Mike Carney of Sun has drafted a proposal along these lines. See: M. W. Carney DHCP Option for IEEE 1003.1 POSIX Timezone Specifications ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-timezone-03.txt (1997-07-30) That draft handles only POSIX-style TZ strings. On July 31 I sent comments to Carney suggesting that support be added for Olson-style strings, and he responded favorably. A copy of those comments is in <ftp://elsie.nci.nih.gov/pub/tzarchive.gz> (look for the string "<199708010208.TAA09225@shade.twinsun.com>"). However, neither Carney's draft nor my comments addressed the problem of incremental update of time zone rules. I'll forward a brief summary of your suggestion to Carney; please feel free to get further involved as well.

Nathan Myers wrote:

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.

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. That said, 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.) The chief objection to "double" is that there is no natural machine-independent representation: even IEEE 754 is insufficient, as the standard does not prescribe the "endian-ness" of the memory layout, and converting to non-IEEE machines would be hideous. Integers, OTOH, are conventionally stored and transferred in big-endian format.

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. My ADOTimeZone class adds a new argument, which I hope to convince Javasoft to propagate into the superclass.

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. Zoneinfo files have a machine-independent format (they use 32-bit ints in big-endian order, which is the same format as IP addresses), and have a maximum size of 1500 bytes or so. There is no need for clients to be able to read the source code at all: "zic" does most of the work. The main problem with "zoneinfo" format, which I have not yet addressed, is that it lacks information past A.D. 2038. Some way will be needed to project the last, or the last two, entries forward into the indefinite (300 million year) future. The main issue is making sure which entries are to be projected. Once this is solved, we have all we need, as nobody knows what changes in time zone information will occur after that date, and by the time we reach it, "zic" will be working with 64-bit Java-style millisecond counts. :-) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org e'osai ko sarji la lojban