[Datetime-SIG] Timeline arithmetic?

[Carl Meyer]

On 09/07/2015 11:28 AM, Tim Peters wrote:
> Short course:  Carl prefers timeline arithmetic, but is not trying to
> change anything about what Python's datetime does by default.  He
> would like a new kind of tzinfo that simultaneously fixes the
> conversion endcases _and_ forces use of timeline arithmetic for all
> operations  Current code would neither be hurt nor helped, only code
> using the new tzinfos would see any difference.  But current code
> trying to use a new tzinfo could break anywhere it relied on classic
> arithmetic.

I did propose that a couple days ago, and found the exercise of
proposing it enlightening :-) but I don't even think that's a good idea
anymore (as of yesterday, when I finally got my head fully around the
internal consistency of the "naive local time" model).

Trying to have both mental models implemented within datetime using
different types of tzinfo would just confuse matters further. Different
types of datetime would be a better bet, but that can just be a
different library altogether.

Better to have datetime be as true to its model as it can, and improve
the intro docs so people assuming a timeline-arithmetic model can also
get their heads around the naive-local-time model and do things the
right way for that model.

> While I'm not entirely sure, best guess is that Carl would also prefer
> that 495 not be implemented.  But his new kind of tzinfo could be
> implemented regardless.  They don't really compete, except in the
> eternal battle over theoretical purity ;-)

No, I would (weakly) prefer for PEP 495 to be accepted, as long as it
chooses to push the required inconsistency into inter-timezone
operations instead of breaking the consistency of classic arithmetic.

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/20150907/aff25a2f/attachment.sig>