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
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/
