[Datetime-SIG] Timeline arithmetic?

[Carl Meyer]

[Tim]
> In other contexts, I wear my "Tim as a Python user hat", "Tim as a
> computer `scientist'" hat, "Tim as an explainer of past decisions"
> hat, "Tim as an advocate for a particular change" hat, "Tim as a
> Python developer" hat, "Tim thinking out loud" hat, and so on.  It's
> absurd to expect consistency among _all_ those roles.  In human
> communication, context is necessary to distinguish, but sometimes
> fails.

I don't expect consistency from humans, it's just that my hat-intuiter
doesn't always work right :-)

[Carl]
>> 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
>> simple cases.
[Tim]
> It would create an "attractive nuisance", yes ;-)

I think that either choice of arithmetic might be an attractive
nuisance; what matters is consistency with the rest of the choices in
the library.

If datetime did naive arithmetic on tz-annotated datetimes, and also
refused to ever implicitly convert them to UTC for purposes of
cross-timezone comparison or arithmetic, and included a `fold` parameter
not on the datetime object itself but only as an additional input
argument when you explicitly convert from some other timezone to UTC,
that would be a consistent view of the meaning of a tz-annotated
datetime, and I wouldn't have any problem with that.

It would be a view consistent with what Guido described a few days ago,
that "noon Eastern on June 3 2020" is not necessarily equivalent to a
UTC instant; it means nothing more than "noon Eastern on June 3 2020"
until you choose to explicitly convert it to UTC, providing a full
zoneinfo definition of "Eastern" (and possibly a `fold` argument too,
though it's not needed for "noon Eastern June 3 2020" unless something
changes) at that moment.

But that isn't datetime's view, at least not consistently. The problem
isn't datetime's choice of arithmetic; it's just that sometimes it wants
to treat a tz-annotated datetime as one thing, and sometimes as another.
(The fact that a _person_ might also want to have one sometimes and
another sometimes is not a reason for an implementation to try to guess
when they want one and when they want another. It could be a reason for
two different types.)

[Tim]
> There is no argument that can possibly succeed for changing arithmetic
> on aware datetimes:  "Tim as Python developer hat" there.  That would
> be massively backward-incompatible.  No chance whatsoever.

Of course! That's abundantly clear, and I'd be every bit as opposed as
you are to a backwards-incompatible change. Can we just assume that if I
refer to "changing arithmetic" it's short-hand for "provide an option
for full consistency in a way that only occurs with an opt-in choice by
the user, leaving existing code behaving identically."

The latter is the only thing I've ever proposed, so your choice to
assume here that I meant the former feels a bit like an intentional
misunderstanding so as to provide an opportunity for unnecessary
hyperbole. Or maybe your intuiter is just fallible too ;-)

> I think making no distinction between "naive time" and "civil time" is
> the core of coherence glitches.  An aware datetime is purely neither
> in the implementation, and different operations treat it in different
> ways.  Wearing many hats, I don't like that.

Yes!

> Wearing my "real life
> Python user" hat, though - eh, I can't really say it's caused me
> problems.

Fair enough. I am also not sure that the consistency glitches are enough
of a problem to be worth fixing. I still think it's useful to clearly
identify them and understand their source.

"What is the root issue" and "is the root issue practically worth fixing
today" are separable questions. I'm still trying to figure out the
former (but I think we're finally getting there); I'm not at all sure
what I think of the latter (and won't be until I try an implementation).

[Carl]
>> (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.
[Tim]
> When wearing several different hats, yes, _that's_ more appealing.
> But kinda pointless, since that's not what's actually done, and PEPs
> have to move on from what _is_ the case.

Of course. But I don't believe at all that understanding the core issues
clearly, and identifying what we'd ideally have chosen initially, is
pointless. It can be very useful (even a precondition) for deciding
_how_ to move on from what is the case.

>> 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.
> 
> That last wasn't ever really a _driving_ force in Python's design.
> From the earlier example, a great many users have complained a great
> many times that
> 
>     1 + "123"
> 
> _doesn't_ return 124.  That _is_ what most casual users expect.  Tough
> luck - Python's not for the terminally lazy.

This example is a false equivalence. Clearly, trying to guess what a
casual user expects to result from an ambiguous operation is a bad idea.
I don't think datetime arithmetic (even on non-UTC datetimes) is an
ambiguous operation, given an implementation that consistently treats
all timezone-aware datetimes as unambiguous instants, or an
implementation that consistently treats them as naive datetimes with a
timezone annotation.

Given an implementation like datetime that isn't sure what they are,
_either_ choice of arithmetic is an attractive nuisance.

> Well, you can't see me, but I really do have a collection of 42 hats
> on the table next to me, and every time I write a reply, sentence by
> sentence I put on the hat most appropriate to what the current
> sentence intends ;-)

That's an excellent image, and I'll keep it in mind :-)

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150904/697d03e4/attachment-0001.sig>