A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2015-September/141763.html below:

[Python-Dev] PEP 495 accepted

[Python-Dev] PEP 495 acceptedAlexander Belopolsky alexander.belopolsky at gmail.com
Tue Sep 22 16:55:50 CEST 2015
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.


> 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 "lossless."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/238793e0/attachment.html>
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4