[Guido] > FYI, I am still completely overwhelmed by this discussion. I recommend that you skip any message with "timeline" in the Subject line ;-) Nobody is actually arguing to make timeline arithmetic (beyond what already exists) any part of PEP 495. But this is a "datetime" SIG, not a "PEP 495" SIG, so it's fair game to discuss it here.
> I will wait until Tim and Alexander tell me there's a PEP to review and > then I'll read that. Carl: if you feel your position is not represented in > that > PEP (even under "rejected alternatives") I recommend that you write > your own PEP. But I really hope that you all will come to an agreement > without competing PEPs! 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. 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 ;-) _______________________________________________ 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/
