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