time zone object

[John Cowan]

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 at ccil.org
			e'osai ko sarji la lojban