[Datetime-SIG] PEP 495: What's left to resolve
tim.peters at gmail.com
Tue Sep 8 23:22:28 CEST 2015
>> But it breaks compatibility: it breaks the rule that for fold=0 nothing
> 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 ;-)
More information about the Datetime-SIG