[Python-ideas] High Precision datetime

[Alexander Belopolsky]

On Thu, May 17, 2018 at 1:33 PM Chris Barker <chris.barker at noaa.gov> wrote:
>
> On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky <
alexander.belopolsky at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180517/f272d146/attachment-0001.html>