Time zone: the next generation

Paul Eggert eggert at CS.UCLA.EDU
Mon Mar 7 07:18:26 UTC 2005


Robert Elz <kre at munnari.oz.au> writes:

> it is entirely reasonable to run a program (for every year data is
> being generated) to calculate Israeli -> Gregorian conversions.

I agree with much of your analysis, but this point might require
some further thought.

It is entirely reasonable run a program for 32-bit time_t, since we
need to generate predictions for future conversions only out to the
year 2038.  It isn't necessarily reasonable to do it for 64-bit
time_t, since (in theory, anyway) we'd need to generate preductions
for future conversions out to the year 292,277,026,596 or so, assuming
I've done the arithmetic right.

This number is a bit silly since it exceeds the commonly predicted
useful life of the universe, but the point is that we'll have to
arbitrarily cut off our predictions somewhere (e.g., 100 years in the
future), and any arbitrary cutoff will be a bit of a pain.

For example, suppose we arbitrarily cut off 100 years into the future.
Do we need to generate new tables every year, as the cutoff time
advances?  This may sound like a trivial issue but in practice trivial
issues like these build up.


> If you're going to have a very wide allowable range, putting some
> limits on what gets converted makes sense.  Pretending we know how
> times and calendars will be done for thousands of years into the
> future is absurd,

But unfortunately it is required for POSIX compliance, at least if
tm_year is representable as an int (true for years up to about 2**31
on most hosts) and if TZ uses the POSIX format.


> Backwards, 1970 is far enough to be accurate.

Here I think you're being a bit too modest in aim.  The existing code
already works for dates back to 1901 (in 32-bit time_t), and some
people already rely on this, to handle time stamps the elderly
(medical records, horoscopes, etc.).  I don't see any technical reason
to remove support for that.

I'd say we might as well go back at least to the introduction of
standard time (circa 1850), for time_t wide enough to support that.  I
don't see any fundamental technical objection to going back that far.



More information about the tz mailing list