[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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
