On Thu, Jul 30, 2015 at 5:25 AM, Guido van Rossum <[email protected]> wrote: > Even if I wouldn't design it that way today (which honestly I haven't > decided whether I would or not) I don't want to change anything about the > observable behavior[1] that would give a different outcome, no matter how > much more "correct" you believe a different outcome would be. The > deprecation time would have be measured in decades. > > The road to improvement that I encourage everyone to explore: add an is_dst > flag (with a different name) and create new timedelta-ish classes that > implement "human" arithmetic (similar to what pytz offers) and "strict" > arithmetic (similar to [NJ]odaTime, IIUC).
I think we can change the behavior datetime.__add__ and datetime.__sub__ if we do it based on the type of the object attached as tzinfo. For example, if we introduce a new abstract subclass of the tzinfo class called say "tzstrict", then we can be sure that there is no tzinfo implementation in the wild that inherits from tzstrict (we fully control the datetime module namespace.) Now, we can make datetime.__add__ and __sub__ check the type of the tzinfo member on its argument(s) and apply the new rules if one of them is an instance of tzstrict. With these changes in place, users who want new aware datetime arithmetic will use timezone implementations that inherit from tzstrict and legacy applications can continue using existing timezone libraries. And we can spend the next decade arguing what kind of timezone implementation belongs to the standard library. :-) _______________________________________________ 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/
