On 23 August 2015 at 09:05, Tim Peters <[email protected]> wrote: >> I wonder why Stuart needed timeline arithmetic? Merely being able to access >> the Olson database doesn't sound enough of a reason for such heroism. > > dateutil also wraps the Olson database (among several other sources of > timezone info), but made no effort to change Python's default > haphazard treatment of folds and gaps. > > I'd be interested to hear Stuart's thoughts on this. Back when I was > searching the web for clues, I mostly saw people (blogs, message > threads) speculating about _conversion_ (not mostly arithmetic) > surprises. Note that once 495-compliant tzinfos exist, zone > conversions using them will work correctly in all cases by magic (no > change to arithmetic is required - classic arithmetic is what's needed > for those and we already have it - conversions today only trip over > the current inability to disambiguate folds - as the docs say, for the > default .fromutc() to mimic the local clock in all cases, .dst() must > consider an ambiguous time to be "in standard time" - which is wrong > "half the time").
My, that was a long time ago. I think interoperability is the biggest issue. Timezones where a big hassle to Australian's writing web applications, because most of the world thought EST meant American Eastern Standard Time while we all knew the correct answer was Australian Eastern Standard Time, or for the rest of the year Australian Eastern Summer Time. So we used timezone aware timestamps to avoid these silly assumptions (and cursed zope.DateTime which hardcoded EST to the USA). And tried to keep all our timestamps in UTC as best practice. But you still had to deal with localized timestamps of course, and converting them to UTC and back to perform arithmetic was a pain in the bum and something lazy devs often didn't bother to do, and that is where the Python implementation fell down. It needed to drop the is_dst flag for pickle size related reasons IIRC, but without that flag you can't do datetime arithmetic that crosses DST boundaries correctly. It had a limitation, and it was documented, and we moved on because apart from this little wart it is a nice module to use and fixing it would have made my ZODB2 database bloat. And then I realized that I could store that single bit of information in the tzinfo instance, and went and implemented pytz because I was young and foolish. And then Gustavo released dateutils, which avoided the issue by avoiding the issue, and prompted me to get off my arse, fix the remaining tests and release it. Conversion was the larger issue, and to do that correctly the arithmetic needed to be fixed. I never thought I was fixing the arithmetic or implementing a particular style - I was just getting my test suite to pass (which is generated from every transition stored in the IANA nee Olson database). -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/ _______________________________________________ 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/
