[Datetime-SIG] PEP 495: What's left to resolve

Alexander Belopolsky alexander.belopolsky at gmail.com
Tue Sep 8 17:46:58 CEST 2015


On Tue, Sep 8, 2015 at 11:09 AM, Guido van Rossum <guido at python.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150908/9a695fad/attachment.html>


More information about the Datetime-SIG mailing list