[Datetime-SIG] IANA TZ database statistics
tim.peters at gmail.com
Thu Sep 24 20:16:59 CEST 2015
>> Just one suggestion: force the year/timestamp into a 400-year span
>> starting at 1971 first (via adding/subtracting multiples of 400
>> years). Then not even Windows will blow up ;-)
> This will work for the future dates (and I think I should use 2100 through
> 2399 range to avoid extending not-regular rules into the far future).
> For the far in the past dates, I still think the earliest transition to standard
> time should be used as the "big bang" transition.
I'm not sure exactly what that means - I'm just trying to worm around
that time_t values less than 0 aren't supported on all systems.
> Note that the 400 year
> hack does not work for systems with 32-bit time_t. I think it is ok to just
> raise OverflowError on those whenever a timezone operation is requested on a
> date outside of EPOCH ± 2**31 range. That's about 140 years.
The 400-year hack is just mindlessly simple. It's possible to do far
better, since there are only 14 possible yearly calendars (which day
of the week is January first, and is it a leap year? 7*2 = 14). So a
table with 14 entries, mapping (weekday_of_1_Jan, is_leap) -> fixed
canonical year is sufficient. Nothing in that depends on the time
zone - it can be precomputed as a static table equally applicable to
all time zones (for years in which "normalization": is desired). In
general, most (*) 28-year spans contain at least one of each possible
yearly calendar. So a 32-bit time_t isn't a real problem here. For
example, any system capable of representing the years from 1972
through 1996 inclusive covers all possible yearly calendars.
(*) Exceptions can occur when the span crosses a century.
More information about the Datetime-SIG