[Nick Coghlan ]
> ...
> 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().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