<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 3:30 PM, ISAAC J SCHWABACHER <span dir="ltr"><<a href="mailto:ischwabacher@wisc.edu" target="_blank">ischwabacher@wisc.edu</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">It's also worth noting that backward compatibility cuts both ways: because Stuart Bishop has chosen to implement timeline arithmetic, any stdlib inclusion of pytz will have to support timeline arithmetic in some form in order to maintain backward compatibility with the package itself. I see how PEP 495 makes it possible to convert datetimes correctly in all cases, but I don't see how it makes it possible to implement time zones that will be pytz-compatible without continuing to require the localize/normalize dance.</blockquote></div><br>The "localize/normalize dance" is part of the backward compatibility guarantee that PEP 495 makes to both datetime and (released) pytz users.  The code that currently works correctly with "localize/normalize dance"  cannot be made to work correctly without it because that will necessarily break some other code that currently works correctly without  "localize/normalize dance."</div><div class="gmail_extra"><br></div><div class="gmail_extra">Stuart has an option of breaking with backward compatibility and releasing a post-PEP 495 pytz2, but we cannot release Python 3.6 that will break every program that uses current versions of pytz or datetutils no matter how strongly we believe that one of the packages is more "correct" than another.</div></div>