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