Ken Pizzini said:
On further reflection I'm less convinced that XML is directly useful (though I'm not opposed to using it for secondary reasons of interchange with other applications, if someone wants to argue that case),
Well, that's a good argument in itself.
* The tzfile format is basically sound. Suggested extensions: . widen timestamps to 64 bits, of course; . add one (or a few?) versioning field(s) --- while the tzh_magic field with a different TZ_MAGIC should be adequate for "version of tzfile", it'd be nice to record something of the character "compiled by tzcode-2004a/zic from tzdata-2005d/africa"; . add support for additional "optional" extension data --- the code written such that it will ignore unknown extensions.
All three of these indicate that we ought to move to a system-independent representation of data. That means either a textual format or a self-describing data format such as ASN.1. I think that textual is far preferable. Once you decide on textual, the choice is between using a standard one or inventing your own. I don't see any significant benefits in not using XML.
* The complexity of interpreting rules on different calendars is all pushed into the preprocessing done by zic; the run-time code need not know anything about them.
No argument there. But I think that both input and output should be XML, preferably with compatible schemas. Actually, thinking further, the zic output could contain both the "compiled" form *and* the original data, so that someone possessing the output can see how it was derived.
* The run-time APIs in this implementation should continue to be limited to the (proleptic) Gregorian calendar, (the one which is mandated by the C and POSIX APIs) (no externally visible change).
Though I still slightly favor the ability to expose a Julian day ("modified" or not), in light of the above am also willing to say that applications which wish to work with dates in non-Gregorian calendars can just base their interconversions on the (tm_year,tm_yday) pair instead.
Given how easy it is to convert between proleptic Gregorian and JD/MJD, I think we should provide these interfaces as a matter of convenience and to prevent endless reinvention of wheels.
Such applications as can handle things like Sweden's multiple transitions to the Gregorian calendar or the calendrical chaos in Rome around the time of Julius Caesar's reign, or the Mayan calendar, or the World calendar, or any other manner of ways that the days have been marked (actual or proposed) in different places and times are quite welcome, but outside the scope of this project.
Fine. Again, though, an XML format would mean that the information could be bundled into the same files if desired. Ditto polygons, etc. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |