On Mon, Aug 24, 2015 at 3:30 PM, ISAAC J SCHWABACHER <[email protected]> wrote:
> 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. 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." 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.
_______________________________________________ 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/
