Review of tzbeta code

[John Cowan]

I believe the proposed mechanism for implementing "Updated" timestamps
is flawed, and should be modified before leaving beta status.

The current design allows either a rule or a zone to be marked
as Updated at a certain time, thus.  Special comments
in the zoneinfo source files of the form

#Updated Zone <zonename> <year> [month day hh:mm:ss]

or 

#Updated Rule <rulename> <year> [month day hh:mm:ss]

are understood as indicating that the specified Zone or Rule was
updated at the specified time.  Each binary zoneinfo file is
marked to indicate the latest #Updated time associated with it.
This is stored in the form "yyyy-mm-dd hh:mm:ss".  The beta
software currently doesn't actually examine the binary stamp,
but the intention is obviously to allow automated supercession
of obsolete zoneinfo files.

The trouble with this stamp, of course, is that it lacks any
indication of time zone!  Formally, this does not matter, because
the data is read from the source files in ASCII form and
written to the binary file in ASCII form.  However, comparing
two binary files to see which one is more current is an
undefined operation, because there is no indication of whether
the stamp is UTC, or the zone's own time, or ADO's personal time zone,
or what.

This will become particularly important if an erroneous source file
is issued, because a correction might very well come out quickly,
in less than a day.  If the correction comes from a different
physical location, the #Updated stamp might appear to be earlier
in time on the corrected file than on the erroneous one.  The results
would be most unfortunate.

This problem could be resolved by convention, such as always using
GMT #Updated values, but this would not be enforced.  It would be
better, IMHO, to require a <zonename> to be supplied.  However, it
would probably be a bad idea to make zic runs depend on the
pre-existence of a zoneinfo implementation, so the <zonename> could be
required to be "GMT" or "UTC".

For the same kinds of reasons, the stamp value in the binary zoneinfo 
files should be stored as a big-endian 32-bit time_t, like other
GMT times.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan at ccil.org
			e'osai ko sarji la lojban