[Nick Coghlan <ncogh...@gmail.com>]
> ...
> Sorry, what I wrote in the code wasn't what I wrote in the text, but I
> didn't notice until Guido pointed out the discrepancy. To get the
> right universal invariant, I should have normalised the LHS, not the
> RHS:
>
>     dt.astimezone(utc).astimezone(dt.tzinfo) ==
>     datetime.fromtimestamp(dt.timestamp())

That's always False, since it's comparing an aware datetime (on the
left) with a naive datetime (on the right).  There's also that,
without a tzinfo argument, .fromtimestamp() creates a naive datetime
via converting to the current system zone (which may have nothing to
do with dt.tzinfo).

So add a dt.tzinfo argument to the .fromtimestamp() call, and then it
will work as intended.

But then it's just saying that two ways of _spelling_ "convert to UTC
and back" are equivalent, which isn't saying much ;-)

Guido's reply gave a clearer invariant:

    dt.timestamp() ==
    dt.astimezone(utc).timestamp() ==
    dt.astimezone(<any other tz>).timestamp()

That's the key point.  If the timestamps are equivalent, then it
follows that conversions to UTC are equivalent (UTC calendar notation
is just another way to spell a POSIX timestamp), and so also that
conversions back from UTC are equivalent.


> For unambiguous times and times in the fold, that's a subset of the

You meant "ambiguous" there?


> stronger invariant:
>
>     dt == dt.astimezone(utc).astimezone(dt.tzinfo) ==
> datetime.fromtimestamp(dt.timestamp())

Same notes as above (always False because ...).


> That stronger invariant is the one that *doesn't* hold for times in
> the gap, as with fold=0 they'll get normalised to use the right UTC
> offset (same UTC time,

Same UTC time as what?  There is no UTC time corresponding to a local
gap time, since the latter "doesn't really exist".  We're making one
up, in the fold=0 case acting as if the user had remembered to move
their clock hands forward when the gap started.  "Garbage in, good
guess out" ;-)

> nominally an hour later local time),

Bingo.

> while with fold=1 they get mapped to an hour earlier in both UTC
> and local time.

Yup.

All obvious to the most casual observer ;-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to