On 08/24/2015 11:18 AM, Guido van Rossum wrote: > I'm still unclear on why pytz solves two problems (timeline arithmetic > and a tzinfo database). What is the linkage between the two besides that > you (Stuart) feels that both are important problems to solve?
Didn't Stuart already answer this in his last email? "Grump. I always interpreted that documentation to mean that timezone conversions where *my* problem as the author of the tzinfo implementation. I thought it was a documented problem to be fixed if/when Python ever provided more complex tzinfo implementations, and one of the reasons it never did provide such implementations in the first place." "Classic behaviour as you describe it is a bug. It sounds ok when you state it as 'add one day to today and you get the same time tomorrow'. It does not sound ok when you state it as 'add one second to now and you will normally get now + 1 second, but sometimes you will get an instant further in the future, and sometimes you will get an instant in the past'." In other words, he just assumed that timeline arithmetic was his only reasonable option as the author of a useful, non-buggy tzinfo implementation. As a user of pytz, it was certainly what I expected, and I'd have considered "classic arithmetic" to be a bug (thanks to pytz, I avoided even knowing that was Python's default behavior until this thread), so I can't fault his assumption. I think the other linkage between the two is that pytz's "every tzinfo instance is fixed-offset" is the most natural way to solve the PEP-495 problem in the absence of PEP 495 and ensure that all datetime instances are unambiguous and valid. Faced with "I need to store this extra disambiguation bit in the tzinfo somehow, to clarify which of two offsets is intended when a timezone transitions from one offset to another", you can either store a boolean somewhere which is usually irrelevant and very hard to name sensibly, or you can "store" the flag by simply assigning a tzinfo instance which represents the specific offset you want (but also knows its full timezone rules, so it can "normalize" to a different offset when asked to). Once you choose the latter implementation (which you might reasonably choose even if you didn't care about arithmetic at all), Python gives you timeline arithmetic automatically. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
