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

Tim Peters tim.peters at gmail.com
Tue Sep 8 06:50:04 CEST 2015


[Guido]
> 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
has `fold=1`.

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 mailing list