Sorry about this. I don't want to talk about leap seconds anymore, but I left a bad impression that intersects with what we _are_ doing.
[Guido] >>> ... >>> I like the idea of using a special tzinfo to reveal the leap seconds for >>> those who really want them. (And we won't have to provide such a tzinfo -- >>> it's enough that one could be written, given a table of leap seconds.) [Łukasz Rekucki] >> But if we don't write a one, how do we know it's possible to do? [Tim] > Because it's a shallow problem: not difficult, just tedious. I should expound on _how_ tedious ;-) The basic template for doing timeline arithmetic is: 1. Convert the datetime(s) to UTC. 2. Do straightforward classic arithmetic in UTC. 3. Convert back to original timezone (except for datetime-datetime subtraction, in which case we're done). This works because, in step #2, classic arithmetic is the same as timeline arithmetic. However, that relies on that Python's current implementation of UTC ignores leap seconds. The approximated UTC is an instance of "naive time". But in a world with UTC leap seconds, that's no longer true. In that world, UTC doesn't match naive time, and classic arithmetic can't work. More is needed then, to move to another kind of time bijectively related to UTC that _does_ match naive time (so that classic arithmetic is correct). Since real-life UTC is defined as an offset (well, a collection of pattern-less offsets) from TAI, and TAI is an instance of naive time, that's the obvious choice. So add: 1.5. Use the frickin' leap second table to convert to TAI. and, in 2, s/UTC/TAI/, and 2.5 Use the frickin' leap second table to convert back to UTC. _______________________________________________ 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/
