Time zone: the next generation

[Clive D.W. Feather]

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 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            |                            |