On Thu, May 17, 2018 at 1:33 PM Chris Barker <chris.bar...@noaa.gov> wrote: > > On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: >> [...] Since the implementation of PEP 495, it is >> possible to represent the 23:59:60 as 23:59:59 with the "fold" bit set. Of >> course, the repeated 23:59:59 will be displayed and behave exactly the same >> as the first 23:59:59, but a 3rd party library can be written to take the >> "fold" bit into account in temporal operations. > > > Does that support the other way -- or do we never lose a leap second anyway? (showing ignorance here) >
I am not sure I understand your question. All I said was that since PEP 495, it became possible to write a pair of functions to convert between TAI and UTC timestamps without any loss of information. For example, around the insertion of the last leap second at the end of 2016, we had the following sequence of seconds: TAI | UTC ---------------------+-------------------- 2016-12-31T23:59:35 | 2016-12-31T23:59:59 2016-12-31T23:59:36 | 2016-12-31T23:59:60 2016-12-31T23:59:37 | 2016-01-01T00:00:00 this correspondence can be implemented in Python using the following datetime objects: TAI | UTC -------------------------------+------------------------------------------- datetime(2016,12,31,23,59,35) | datetime(2016,12,31,23,59,59) datetime(2016,12,31,23,59,36) | datetime(2016,12,31,23,59,59,fold=1) datetime(2016,12,31,23,59,37) | datetime(2016,1,1,0,0,0) Of course, Python will treat datetime(2016,12,31,23,59,59) and datetime( 2016,12,31,23,59,59,fold=1)as equal, but you should be able to use your utc_to_tai(t) function to translate to TAI, do the arithmetic there and translate back with the tai_to_utc(t) function. Wherever tai_to_utc(t) returns a datetime instance with fold=1, you should add that to the seconds field before displaying. > But still, now datetime *could* support leap seconds (which is nice, because before, 23:59:60 was illegal, so it couldn't even be done at all), but that doesn't mean that it DOES support leap seconds.... By the same logic the standard library datetime does not support any local time because it does not include the timezone database. This is where the 3rd party developers should fill the gap.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
