Time zone: the next generation
Clive D.W. Feather
clive at demon.net
Tue Mar 8 12:08:22 UTC 2005
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
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
> . 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
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 at demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive at davros.org> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | |
More information about the tz