[Tim] >> 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 ;-)
[Alex] > 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). That's fine. > 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. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
