[Datetime-SIG] Timeline arithmetic?
carl at oddbird.net
Fri Sep 4 19:37:47 CEST 2015
> But you have to know by now that datetime always intended that apps
> needing timeline arithmetic use UTC instead (or timestamps), and
> there's scarcely an experienced voice on the planet that would
> _recommend_ doing it any other way. Building in "by magic" timeline
> arithmetic would be fighting both datetime's design and universally
> recognized best practice.
I find this argument a bit disingenuous - though it depends what exactly
you are arguing, which isn't clear to me.
All else being equal, designing a green-field datetime library,
"universally recognized best practice" does not provide any argument for
naive arithmetic over aware arithmetic on aware datetimes. Making the
choice to implement aware arithmetic is not "fighting" a best practice,
it's just providing a reasonable and fully consistent convenience for
You could perhaps argue that implementing _any_ kind of arithmetic on
aware non-UTC datetimes is unnecessary and likely to give someone, at
some point, results they didn't expect, and that it should instead just
raise an exception telling you to convert to UTC first.
The fact that best practice is to manipulate datetimes internally in UTC
(meaning the use case already has a usually-better alternative) can
certainly _weaken_ the argument for bothering to _change_ the behavior
of arithmetic on aware datetimes, once it's been implemented otherwise
for many years. That may be all you're trying to say here, in which case
I fully agree.
The core arguments _for_ aware arithmetic on aware datetimes are:
1) Conceptual coherence. Naive is naive, aware is aware, both models are
fully internally consistent. Mixing them, as datetime does, will never
be fully consistent. You may call this "purity" if you like, but the
issues with PEP 495 do reveal a lack of coherence in datetime's design
(that is, that it lacks a consistently-applied notion of what a
tz-annotated datetime means). I think you've admitted this much
yourself, though you suggested (in passing) that it could/should have
achieved coherence in the opposite direction, by disallowing all
comparisons and aware arithmetic (that is, all implicit conversions to
UTC) between datetimes in different timezones.
2) Principle of least surprise for casual users. On this question, "you
should use UTC for arithmetic" is equivalent to "you should use a period
recurrence library for period arithmetic." Both arguments are true in
principle, neither one is relevant to the question of casual users
getting the results they expect. There may of course be legitimate
disagreement on which behavior is less surprising for casual users.
Unfortunately I don't think datetime.py (even in its many years of
existence) has given us useful data on that, since it never included a
timezone database and most people who need one use pytz.
It's often unclear to me when you're trying to justify datetime's design
choices, and when you're just pointing out that the bar is really high
for changing established "good enough" behavior. If you want me to shut
up and stop arguing with you (which would be an eminently reasonable
desire!) clarifying that it's the latter more than the former would help
tremendously, because on the latter point I agree completely.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG