[Datetime-SIG] Another round on error-checking

[Carl Meyer]

[Tim]
> 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:

I don't think this cuts to the heart of anything :/ I think it avoids
the main point I've made (several times) to latch instead onto a tangent
I should have left out.

[Tim]
> That's the heart:  you simply despise classic arithmetic.

Sorry, but no. I have nothing at all against naive arithmetic. I think
both naive arithmetic and timeline arithmetic have good use cases.

What I have trouble with is a tz-annotated datetime object that
fundamentally can't decide whether it's living in a naive or timeline
model, and thus behaves unpredictably.

This is a problem today, but at least the behavior can be explained
fairly simply: the model is naive when operating within the same
timezone, and aware anytime you're converting between timezones or
interoperating between timezones.

PEP 495, AFAICS, makes the problem worse, because it introduces another
bit of information that only makes sense in a timeline view. That new
bit now allows round-tripping from UTC, which is great (no problem,
because conversions are an area where tz-annotated datetimes already
tried to behave as tz-aware instants in time). But then it can't quite
decide how to rationalize that new bit of information with its naive
internal view of time, so it settles on a mish-mash of inconsistent
behavior that violates basic arithmetic identities we all learned in
elementary school and only makes any sense if you've followed this
entire thread.

If you want to cut to the heart of the matter, tell me how you would
write the documentation for how arithmetic works on a tz-annotated
datetime post-PEP-495. Does it work on a naive "move the hands of the
clock" model? (No, because I can subtract 1:30AM from 2:30AM and get "2
hours" in some cases.) Does it work on a UTC timeline model? (No,
clearly not.) So what is the model, stated precisely and concisely?

And is it actually backwards-compatible with current code that converts
from UTC to local time and then does arithmetic on those local times, or
compares them to each other? (Not around a DST transition, no.)

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/20150903/20142158/attachment.sig>