[Datetime-SIG] PEP 495: What's left to resolve
tim.peters at gmail.com
Tue Sep 8 06:50:04 CEST 2015
> Maybe I should just reject PEP 495 in disgust. :-)
Maybe so :-)
> I think #2 is the only reasonable solution (of these three).
No argument there either.
> Of all the
> existing semantics we're trying to preserve, I find interzone comparison the
> unholiest. (With the possible exceptions of the case where both zones are
> known to be forever-fixed-offset, such as datetime.timezone instances and
> pytz.utc, and even possibly the fixed-offset zones that pytz returns from
> localize(). How exactly we're going to recognize those is a different
> question, though I have an opinion there too.)
No real worries about those: if 495 is implemented, there will be two
kinds of tzinfos:
1. With pre-495 semantics. Those will never even look at `fold`, let
alone set it to 1.
2. With post-495 semantics. .fromutc() is the only tzinfo method that
will set `fold`. Any correct implementation of .fromutc() converting
to a fixed-offset zone will always set `fold` to 0 in its result,
since there are no ambiguous times in a fixed-offset zone.
There are two flavors of "solution 2" (which differ in how much they
muck with interzone subtraction and/or comparison), but neither of
those flavors changes anything about what happens when neither operand
So the only way by-magic cross-zone subtraction or comparison between
fixed-offset zones could cease working exactly as they do today is if
the user forces `fold=1` manually. And by "the only way", I mean the
only way I just happened to think of ;-) But it's certain a correct
495 .fromutc() could not screw this up.
Note that intrazone arithmetic ignores `fold` in the current proposal
(classic arithmetic changes in no way, ever), but always forces it to
`0` when there's a datetime result. So some stray fold=1 propagating
through intrazone datatime arithmetic isn't a concern either.
More information about the Datetime-SIG