[Datetime-SIG] Another round on error-checking

[Tim Peters]

[Tim]
>> It's unreasonable to ask people to settle for arithmetic at best 10x
>> slower just to get correct timezone conversions

[Chris Barker]
> I'm not sure. As has been pointed out, best practice is to use UTC or
> naive time anyway.

We're not designing a new language here.  Python already has more
users than an instance of numpy.datetime64 has bits ;-)

As is, working in UTC does nothing to help you get correct conversions
in all cases.  That problem has nothing to do with arithmetic.  It has
entirely to do with what PEP 495 is addressing:  the current inability
of a local time to record _which_ UTC time it corresponds to in
ambiguous cases.  timeline vs classic arithmetic is irrelevant to that
"in theory".  In practice, it seems to be unfortunately true that
resolving it in a way that plays nice with everything else requires
muddying the classic arithmetic rules in some rare cases.


> So if the casual user wants to compute how long s/he slept last night,
> it can be slow. It's easier to document "computations are much faster
> in UTC" than to document all the surprising inconsistencies.

Ditto.

> And as for original intent -- my understanding of the entire
> architecture was designed NOT to be about fast arithmetic.

Quite so.  But it's been in the field for over a decade, and
relatively fast arithmetic happens to a property that's been
maintained all along.  That's another kind of "backward compatibility"
we have to respect.

> If you want that, use tics or numpy.datetime64.

Or just leave your already-working Python datetime "fast enough" code alone.


> And intentional or not, "classic" arithmetic may be easy to implement
> and fast, but it is hard to explain, surprising, and not very useful.

I find it very useful.  So does Guido.  As to being hard to explain,
you must be joking:  classic arithmetic has the same semantics as
doing integer arithmetic on integer POSIX timestamps (although
extended to support microseconds).  They're different representations
of the same thing.  I would have _preferred_ that an aware datetime
followed timeline rules instead (or didn't support builtin arithmetic
at all), but too late for that.