On Tue, Sep 8, 2015 at 11:09 AM, Guido van Rossum <[email protected]> wrote:
> But it breaks compatibility: it breaks the rule that for fold=0 nothing > changes. It preserves a "weak form" of compatibility: nothing changes in the behavior of aware datetime objects unless they use a post-PEP tzinfo. Note that Solution 2 also breaks a "strong form" of compatibility (nothing changes unless fold=1) because pre-PEP tzinfos are supposed to interpret times in the fold as STD (fold=1). Note that in my experience very few tzinfo developers understand this requirement and with a run-of-the-mill tzinfo you have a 50/50 chance that it will interpret ambiguous times as fold=0 or fold=1. Note that PEP 495 in its present form does not promise a "strong form" of compatibility. This is something you wanted to have with fold=-1, but I thought I convinced you that it was not necessary. The current compatibility promise of PEP 495 is that fold attribute is ignored unless it is explicitly checked in tzinfo.utcoffset() and friends implementations. This stays under Solution 2 because u_ and v_ conversions are always the same if utcoffset() ignores the value of fold. Once you decide to use a post-PEP tzinfo, you have no choice but to test your software on the edge cases if you care about them. (And you probably do if you bother to switch to a post-PEP tzinfo.) If you don't care about edge cases, you can continue using pre-PEP tzinfos or switch and accept a more consistent but different edge case behavior.
_______________________________________________ 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/
