[Chris Barker <[email protected]>] > It seems to me that it's clear that timeline arithmetic will not get > implemented in concert with PEP 495.
It's certainly not _part_ of 495. 495 aims to fix timezone conversions in all cases for code that's already working fine in all other respects. Tying that to timeline arithmetic would wholly miss the "for code that's already working fine" goal. Carl's scheme would tie fixing conversions _to_ using a brand new builtin implementation of timeline arithmetic, so would do nothing for existing code (would neither hurt nor help it, although all code currently doing arithmetic on aware datetimes could fail in subtle or gross ways _if_ it tried using one of Carl's new tzinfos). > So -- is the door open to a PEP that DOES implement timeline > arithmetic with tz-aware datetimes in the standard lib? I would say instead the door isn't shut ;-) Note that Guido already rejected PEP 500, which proposed one way to allow it. He didn't like its generality. A PEP concerned with timeline arithmetic alone would overcome that objection. But you have to know by now that datetime always intended that apps needing timeline arithmetic use UTC instead (or timestamps), and there's scarcely an experienced voice on the planet that would _recommend_ doing it any other way. Building in "by magic" timeline arithmetic would be fighting both datetime's design and universally recognized best practice. So I dare to say it will never be _attractive_ to Guido. At best it could get grudging acceptance. Which is possible! Just want to make clear that it's likely to be an uphill fight. Note that PEP 495 may also be rejected. "Grudging acceptance" is the best 495 can do too (always-correct conversions are an interest of mine, not particularly of Guido's - but, to be fair, at least Guido doesn't hate the idea of fixing conversions ;-) ). > ... > Also, particularly as PEP 495 will introduce changes to tzinfo, that will > presumable lead to changes in tzinfo implementations (like pytz, etc), it > seems that if other changes are afoot, now is a good time to map out how > they should be done. It seems 495 really doesn't do anything for pytz, so I'm not sure Stuart would bother to implement 495-conforming tzinfos. _Someone_ will, though. Eventually ;-) > Stuart, if you are listening: > > IIUC, you want "timeline" arithmetic to work with pytz tzinfo-aware > datetimes. To the extent that the current implementation functions in a > maybe "hacky", and at least inconvenient, way to achieve this. > > So you are an obvious person to say what we might put in the stdlib that > would facilitate cleaning all that up. If anything. > > BTW: I'll at least take it as a given that we're not breaking backward > compatibility, and that arithmetic needs to stay as fast as it currently is > -- at least in the cases where it currently works. A timeline arithmetic PEP would have to ensure that timeline arithmetic is never used unless a programmer explicitly asks for it. PEP 500 met that goal, and so does Carl's scheme (both via the same basic mechanism: by the user asking for a new flavor of tzinfo). _______________________________________________ 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/
