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
23 matches
Mail list logo
