Re: [Python-Dev] PEP 495 accepted

2015-09-23 Thread Tim Peters
[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


Re: [Python-Dev] PEP 495 accepted

2015-09-23 Thread Nick Coghlan
On 24 Sep 2015 01:21, "Tim Peters"  wrote:

>
> 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.

Thanks for the additional clarifications all, I'm confident I understand
now :)

Might it be worth mentioning Guido's invariant in the section of the PEP
about the timestamp method?

Cheers,
Nick.
___
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


Re: [Python-Dev] PEP 495 accepted

2015-09-23 Thread Alexander Belopolsky
>
> [Tim Peters]
>
> >
> > Guido's reply gave a clearer invariant:
> >
> > dt.timestamp() ==
> > dt.astimezone(utc).timestamp() ==
> > dt.astimezone().timestamp()
>
> [ Nick Coghlan]

> Might it be worth mentioning Guido's invariant in the section of the PEP
> about the timestamp method?
>
The case of missing time in Guido's invariant is rather subtle.  What is
happening is that .timestamp()  and .astimezone(..) methods use the same
"normalization" to interpret what dt means.  This is not obvious in the
expression above.  Particularly in dt.astimezone().timestamp().  Here, if instead of  we pass dt.tzinfo,
then .astimezone(..) becomes a noop and "normalization" happens in
.timestamp().  I don't think exposing all this in the PEP will help.  Let's
return to this when it is time to write the reference documentation.
___
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