On 09/24/2015 04:47 AM, Nick Coghlan wrote:
> 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()
>>
> Might it be worth mentioning Guido's invariant in
>
> [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
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 equi
[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) ==
>
On 23 September 2015 at 01:09, Alexander Belopolsky
wrote:
>
> On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky
> wrote:
>>
>> On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum
>> wrote:
Based on the UTC/local diagram from the "Mind the Gap" section, am I
correct in thinkin
Yeah, sadly the point where we *should* have made this clean break was in
3.0. That's where e.g. inequalities between a string and a number, or
between either type and None, were changed from returning something
"arbitrary but stable" into raising TypeError. It's much harder to break it
now, even w
[Guido]
>> it is broken, due to the confusion about classic vs. timeline arithmetic
>> -- these have different needs but there's only one > operator.
[Alex]
> I feel silly trying to defend a design against its author. :-)
"Design" may be an overstatement in this specific case ;-)
I remember impl
On Tue, Sep 22, 2015 at 4:14 PM, Nathaniel Smith wrote:
> Is there a good argument against at least deprecating inequality
> comparisons and subtraction between mixed timezone datetimes?
That's a wrong question. The right question is: "Is current behavior
sufficiently broken to justify a backw
On Sep 22, 2015 1:09 PM, "Alexander Belopolsky" <
alexander.belopol...@gmail.com> wrote:
>
>
> On Tue, Sep 22, 2015 at 3:32 PM, Guido van Rossum
wrote:
>>
>> it is broken, due to the confusion about classic vs. timeline arithmetic
-- these have different needs but there's only one > operator.
>
>
On Tue, Sep 22, 2015 at 3:32 PM, Guido van Rossum wrote:
> it is broken, due to the confusion about classic vs. timeline arithmetic
> -- these have different needs but there's only one > operator.
I feel silly trying to defend a design against its author. :-) Yes, a
language with more than one
On Tue, Sep 22, 2015 at 11:26 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum
> wrote:
>
>> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>>> such cases (those where "==" would have returned True had
[Guido]
>>> I think we should change this in the PEP, except I can't find where
>>> the PEP says == should raise an exception in this case.
[Tim]
>> It doesn't - the only comparison behavior changed by the PEP is in
>> case of interzone comparison when at least one comparand is a "problem
>> time"
On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum wrote:
> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>> such cases (those where "==" would have returned True had it not been
>> forced to return False - then "<" and ">" will also be False).
>>
>> In any case, nothing c
On Tue, Sep 22, 2015 at 10:34 AM, Tim Peters wrote:
> [Tim]
> >> Sure - no complaint. I was just saying that in the specific,
> >> complicated, contrived expression Nick presented, that it always
> >> returns False (no matter which aware datetime he starts with) would be
> >> more of a head-scra
[Tim]
>> Sure - no complaint. I was just saying that in the specific,
>> complicated, contrived expression Nick presented, that it always
>> returns False (no matter which aware datetime he starts with) would be
>> more of a head-scratcher than if it raised a "can't compare naive and
>> aware date
On Tue, Sep 22, 2015 at 12:47 PM, Tim Peters wrote:
>
> I was just saying that in the specific,
> complicated, contrived expression Nick presented, that it always
> returns False (no matter which aware datetime he starts with) would be
> more of a head-scratcher than if it raised a "can't compare
On Tue, Sep 22, 2015 at 9:47 AM, Tim Peters wrote:
> [Tim]
> >>> ...
> >>> The
> >>> top-level operation on the RHS is datetime.fromtimestamp(). However,
> >>> it didn't pass a tzinfo, so it creates a naive datetime. Assuming dt
> >>> was aware to begin with, the attempt to compare will always
[Tim]
>>> ...
>>> The
>>> top-level operation on the RHS is datetime.fromtimestamp(). However,
>>> it didn't pass a tzinfo, so it creates a naive datetime. Assuming dt
>>> was aware to begin with, the attempt to compare will always (gap or
>>> not) raise an exception.
[Tim]
>> Oops! In current
On Tue, Sep 22, 2015 at 8:16 AM, Tim Peters wrote:
> [Tim]
> > ...
> > The
> > top-level operation on the RHS is datetime.fromtimestamp(). However,
> > it didn't pass a tzinfo, so it creates a naive datetime. Assuming dt
> > was aware to begin with, the attempt to compare will always (gap or
>
On Tue, Sep 22, 2015 at 11:11 AM, Tim Peters wrote:
> [Nick Coghlan]
> ...
> >>> dt ==
> >>>
> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
> ...
> [Guido]
> >> That can't be right -- There is no way any fromtimestamp() call can
> return
> >> a time in the gap.
[Tim]
> ...
> The
> top-level operation on the RHS is datetime.fromtimestamp(). However,
> it didn't pass a tzinfo, so it creates a naive datetime. Assuming dt
> was aware to begin with, the attempt to compare will always (gap or
> not) raise an exception.
Oops! In current Python, comparing nai
[Nick Coghlan]
>>> 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
On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum
> wrote:
>
>> Based on the UTC/local diagram from the "Mind the Gap" section, am I
>>> correct in thinking that the modified invariant that also cov
On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum 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.tzi
On Tue, Sep 22, 2015 at 3:01 AM, Nick Coghlan wrote:
> ... 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()".
On Tue, Sep 22, 2015 at 12:01 AM, Nick Coghlan wrote:
> It turns out there's one aspect of the accepted proposal that I
> *think* I understand, but want to confirm: the datetime -> POSIX
> timestamp -> datetime roundtrip for missing times.
>
> If I'm reading the PEP correctly, the defined invaria
On 22 September 2015 at 13:33, Nick Coghlan wrote:
> On 22 September 2015 at 08:03, Guido van Rossum wrote:
>> Just so people know, over at the datetime-sig I've accepted PEP 495, which
>> adds a fold flag to datetime objects to distinguish ambiguous times. This
>> enables roundripping of convers
On 22 September 2015 at 08:03, Guido van Rossum wrote:
> Just so people know, over at the datetime-sig I've accepted PEP 495, which
> adds a fold flag to datetime objects to distinguish ambiguous times. This
> enables roundripping of conversions for those times where the local clock is
> moved bac
More context ;-)
PEP 0495 -- Local Time Disambiguation
Abstract
This PEP adds a new attribute fold to instances of the datetime.time
and datetime.datetime classes that can be used to differentiate
between two moments in time for which local times are the same. The
allowed values for the fold att
Just so people know, over at the datetime-sig I've accepted PEP 495, which
adds a fold flag to datetime objects to distinguish ambiguous times. This
enables roundripping of conversions for those times where the local clock
is moved backward (creating ambiguous times that could not be distinguished
30 matches
Mail list logo
