<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 11:09 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But it breaks compatibility: it breaks the rule that for fold=0 nothing changes.</blockquote></div><br>It preserves a "weak form" of compatibility: nothing changes in the behavior of aware datetime objects unless they use a post-PEP tzinfo.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>