[Python-Dev] PEP 495 accepted

Alexander Belopolsky alexander.belopolsky at gmail.com
Tue Sep 22 17:09:00 CEST 2015


On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum <guido at python.org>
> wrote:
>
>> 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()".
>>>
>>
>> That can't be right -- There is no way any fromtimestamp() call can
>> return a time in the gap.
>>
>
> I don't think Nick said that.
>

On the second reading, it looks like Nick's second sentence contradicts his
first.  Guido is right.  Moreover, there is no way to get a time in the gap
as a result of any conversion including astimezone() and fromutc() in
addition to fromtimestamp().   Such datetimes may appear if you construct
them explicitly, use .replace() to transplant a datetime to another
timezone (or modify other components) and in the result of datetime +
timedelta operation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/f0e2334f/attachment.html>


More information about the Python-Dev mailing list