[Datetime-SIG] Another round on error-checking

[Alexander Belopolsky]

On Tue, Sep 1, 2015 at 1:44 PM, Tim Peters <tim.peters at gmail.com> wrote:

> [Alex]
> > Here is an idea that I think may work: let's consider fold=1 instances
> as if
> > they have a different tzinfo instance from the other side in both
> datetime
> > subtractions and comparisons.  This will be consistent with the current
> > stdlib and pytz work-arounds of representing "second" times using
> fictitious
> > fixed-offset timezones.
>
> That's what I was getting at by saying "fold=1 veritably _screams_
> 'I'm no longer working in naive time'".  Which implies "I need
> timeline arithmetic", and everything else follows from that, including
> hash() not ignoring fold=1 either.
>
> But then the concept of "naive time" gets muddier:  sometimes, e.g.,
>
>      dt1  - dt2
>
> in a common zone (same tzinfo) will use classic arithmetic, but in
> other cases (fold=1 in at least one) timeline arithmetic.
>

I don't think this is a problem as long as we disallow mixing naive and
aware instances in arithmetic and ordering and keep naive ≠ aware always
rule.


>
> And there's also that, after
>
>     d = dt1 - dt2
>
> I suspect it may no longer always be the case that
>
>     dt1 == dt2 + d
>
> (unsure, but can't make time for it now)
>

That's the price we pay for classic arithmetic anyways.  I am not even sure
we want to trigger timeline arithmetics in dt + delta expressions when
dt.fold=1.  If you do, dt - hour + hour will still not take you back
because the seconds + hour will be classic.

I don't think we can ever get rid of all paradoxes here.  Once you let your
time go back, all bets are off.  What we can do is to shift them from one
place to another so that you only see odd behavior when a fold=1 instance
is involved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150901/0f495117/attachment.html>