[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...

Tim Peters tim.peters at gmail.com
Thu Aug 20 02:46:00 CEST 2015


[Alexander Belopolsky]
> /// let me substantiate my claim about 10x performance penalty.
>
> $ python3 -m timeit -s "from datetime import datetime, timezone; t = datetime.now(timezone.utc); l = t.astimezone()" "l - t"
> 1000000 loops, best of 3: 0.448 usec per loop
> $ python3 -m timeit -s "from datetime import datetime, timezone; t = datetime.now(); l = t" "l - t"
> 10000000 loops, best of 3: 0.0444 usec per loop
>
> Currently, subtracting aware datetimes with the same tzinfo incurs no
> penalty
>
> $ python3 -m timeit -s "from datetime import datetime, timezone; t = datetime.now(timezone.utc); l = t" "l - t"
> 10000000 loops, best of 3: 0.0436 usec per loop
>
> With PEP 500, we can have timeline arithmetic without the overhead of two
> round trips to tzinfo.   I will be happy if someone would demonstrate how to
> achieve the same by simpler means.

In general, I agree timeline arithmetic "belongs in" tzinfo objects.
As you've said elsewhere, the tzinfo interface gives general datetime
code a microscopically tiny understanding of how a given timezone
works; in effect, it can only ask what the total UTC offset and DST
offset are at a single microsecond in local time, or what a single
microsecond in UTC time looks like in local time.  Code outside the
tzinfo can't _deduce_ anything more generally applicable from any of
that; code inside the tzinfo knows everything about how the timezone
works.

But in the specific case above, I'd call the specter of slowdowns a
QOI (quality of implementation) issue.  For
eternally-fixed-offset-and-eternally-fixed-timezone-name timezones
(including UTC), classic and timeline arithmetic are exactly the same
thing.  A high-quality wrapping of timezone info should take advantage
of that, by _not_ using whatever spelling of "this tzinfo object wants
timeline arithmetic" is introduced for such timezones.  In which case,
the naive arithmetic shortcuts will continue to be used for such
timezones.

I expect this will be crucial for timezone.utc (should be a
requirement), so that code implementing fancier stuff can _rely_ on
that doing arithmetic on UTC instances won't fall into the kinds of
infinite regress Lennart got buried under, and without needing endless
annoying and time-consuming dances to strip and re-attach the tzinfo
object (to force classic arithmetic).


More information about the Datetime-SIG mailing list