[Python-Dev] PEP 495 accepted

[Tim Peters]

[Nick Coghlan]
>>> Based on the UTC/local diagram from the "Mind the Gap" section, am I
>>> correct in thinking that the modified invariant that also covers times
>>> in a gap is:
>>>
>>>     dt ==
>>> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
>>>
>>> That is, for local times that exist, the invariant "dt ==
>>> dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that
>>> don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise
>>> them to be a time that actually exists in the original time zone, and
>>> that normalisation also effectively happens when calling
>>> "dt.timestamp()".

[Guido]
>> That can't be right -- There is no way any fromtimestamp() call can return
>> a time in the gap.

[Alexander Belopolsky]
> I don't think Nick said that.

I do, except that he didn't ;-)  Count the parens carefully.  The
top-level operation on the RHS is datetime.fromtimestamp().  However,
it didn't pass a tzinfo, so it creates a naive datetime.  Assuming dt
was aware to begin with, the attempt to compare will always (gap or
not) raise an exception.  If it had passed dt.tzinfo, then Guido is
right.


>> I think about the only useful invariant here is
>>
>>   dt.timestamp() == dt.astimezone(utc).timestamp() ==
>>      dt.astimezone(<any other tz>).timestamp()

> Yes, this is just another way to say that  .astimezone() conversions are now

Nick, to be very clear, there are two scenarios here after PEP 495 is
implemented in Python:

1. You're using a pre-495 tzinfo.  Then nothing changes from what happens today.

2. You're using a new 495-conforming tzinfo.  Then the discussion
starts to apply.