[Datetime-SIG] Conversion vs arithmetic (was Re: Is EDT a timezone? Was: PEP-0500)
alexander.belopolsky at gmail.com
Mon Aug 24 21:45:56 CEST 2015
On Mon, Aug 24, 2015 at 3:30 PM, ISAAC J SCHWABACHER <ischwabacher at wisc.edu>
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG