[Datetime-SIG] Another round on error-checking

[Tim Peters]

I'm out of time for tonight, but will try to make more tomorrow.  Just
one for now, because I think it cuts to the _real_ heart of this batch
of messages:

[Carl Meyer <carl at oddbird.net>]
> ...
> If a new Python user is trying to calculate how long they slept when
> they went to bed at 10pm on March 2 and got up at 6am on March 3, Python
> should give them the right answer.  Telling them "you should convert
> to UTC first if you want your tz-aware datetime to actually be aware of
> the tz transition" is going to sound a bit silly to them; they neither went
> to sleep in UTC nor awoke in UTC; they did both in their own timezone.

That's the heart:  you simply despise classic arithmetic.  This
example has nothing to with PEP 495 - it's a complaint about classic
arithmetic, period.

It's more likely that a new user will want to set an alarm to get up
at 6am, then add timedelta(days=1) to set a new alarm for "same time
next day".  They'd be surprised and annoyed if that ended up at 7am or
9am just because DST switched.  Their stupid alarm-setting code works
fine today, and will continue to work fine with a 495-compliant tzinfo
when they're available.

It doesn't help to point out that "period arithmetic" _could_ be done
in some other way.  These particular kinds of uses already work, and
always have.

Different purposes require different kinds of arithmetic.  Python
picked one.  That timeline arithmetic wasn't the choice doesn't mean
Python despises it.  It was just judged "probably less useful overall
- and there are other, better ways to get it".  You can disagree with
that choice, but it can't be changed now.  I know, you're not
proposing to change it:  you're proposing to leave it exactly the way
it is, but exploit the desire for correct timezone conversions to
sneak timeline arithmetic into the core - because that's "the only
sane way" to do it.  Tricky ;-)

Once your new user understood the _potential_ problems when dealing
with pseudo-real-world durations in classic arithmetic, no, for
something this trivial I wouldn't advise converting to UTC explicitly.
Instead I'd give them a 1-line Python function implementing timeline
datetime-datetime subtraction, which they can use forever after.  It
can't always work right today, because conversions alone can't always
work right today.  When the user obtains a 495-compliant tzinfo , the
same function will always work right, by magic.

But _only_ under 495.  Under your view, timezone conversion would
continue to fail in some cases, because users who didn't want to drink
the timeline-all-the-time Kool-Aid would be left out.  Also left out
would be users who usually want classic arithmetic but _do_ convert to
UTC for fancier stuff:  conversion to UTC would continue to give rare
wrong results for them too.

So you're not really looking to do anything for anyone, _except_ for
those who want the whole timeline enchilada.  That's a legitimate
view, but in particular it wouldn't help me a bit ;-)  I _want_ what
495 is offering.  I usually want classic arithmetic.  When I want
timeline arithmetic, I switch to UTC, or use a 1-liner, and I'd sleep
a tad better if the latter two always did work correctly.

BTW, if your new user is also a physicist, we'[ll _both_ need to give
them a much more annoying function, in case they ask the question near
the end of June or December, and need to account for a leap second
that may have occurred while they were sleeping.