[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. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
