time zone object

[Nathan Myers]

John Cowan <cowan at 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 at cantrip.org