Time zone: the next generation

[Clive D.W. Feather]

Ken Pizzini said:
>      * a "Modified Julian Date" (Gregorian 1970-01-01 CE == MJD 40587)
>        [specified relative to a convenient-to-the-program location
>        on earth, not necessarily the location mentioned above]

Why MJD and not true Julian Date?

> Slightly more ambitious,
> but still within the bounds of reason, we may wish to add support for
> the Hebrew calendar (which we would need to do internally anyway,
> if we wish to support the new time zones in Israel without having
> to resort to the current solution of special-casing every year).

There's other purely algorithmic calendars that could be added relatively
simply as well.

> We may also wish to add ephemeris calculations so that we can correctly
> adjust for local-sun-time, whether for Saudi Arabia in the late 1980s,
> or for pre-timezone locales (or not).

I'm a little more nervous of this, because you start to run into issues
like leap seconds that could affect the answers.

> Thinking about the broader problem a little more, perhaps it would
> make sense to use XML for the run-time format?

Very definitely. Looking at your (elided) example I can see several places
where a nested structure would be preferable, and once you've gone that way
you might as well do XML.

> The bad thing is that it would either add an
> external dependency to the code, or require that we bundle a parser.

If you assume that the incoming files are lexically correct, a parser is
actually pretty simple.

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