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

[Tim Peters]

[Guido]
>> But it breaks compatibility: it breaks the rule that for fold=0 nothing
>> changes.

[Alex]
> It preserves a "weak form" of compatibility: nothing changes in the behavior
> of aware datetime objects unless they use a post-PEP tzinfo.

In that specific way, it's "more backward compatible" than the
"special-case-the-snot-out-of-fold=1 in interzone __eq__ and __ne__",
but it's subtle:

Some datetime class constructors, like .now() and today(), can set
fold=1 even if no post-495 tzinfos exist, based on Python's own idea
of what the system zone rules are.

If one of those happens to be generated during a repeated time in the
system zone, and a pre-495 tzinfo is attached, then special-casing
fold=1 makes it "not equal" to anything in any other zone despite that
a pre-495 tzinfo is in use.  That's certainly breaking _some_ form of
backward compatibility, however obscure.

But under Alex's latest idea, that wouldn't break:  the pre-495
tzinfo's .utcoffset() would return the same thing regardless of
`fold`, so the new __eq__ wouldn't see any problem with it.  The
latest idea is based on determining whether a time is _really_ "a
problem case", and to a pre-495 tzinfo nothing is.  Just staring at
`fold` without consulting the tzinfo is guessing at whether it _might_
be a real problem for the tzinfo in use, and in fact always guesses
wrong when fold=1 and a pre-495 tzinfo is in use.


> 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.

Well, if they copied the Python doc examples, they got this "right".
If they're using dateutil's wrappings, they also got this right.  And
it's a non-issue in pytz, because that only ever uses fixed-offset
classes.  The three users who remain will just have to eat their own
hasty cooking ;-)


> ...
> 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.

Yup!  The new idea is cleaner and clearer.  But runs slower ;-)