Time zone: the next generation
Clive D.W. Feather
clive at demon.net
Mon Mar 7 11:36:19 UTC 2005
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 | |
More information about the tz