Hi,
as I ran across an issue on leap seconds elsewhere, I wondered if/how they are dealt with in the UTCDateTime object.
In [73]: t0 = UTCDateTime(2017,1,1)
In [74]: t0 -1
Out[74]: 2016-12-31T23:59:59.000000Z
... while in principle t0-1 should be 2016-12-31T23:59:60.000000Z due to the recent leapsecond.
With 27 leapseconds since 1972 this might be a problem in some use cases.
Has this been considered somewhere in the development?
Cheers
Christian
Hi Christian,
currently UTCDateTime is not aware of leap seconds. We have some discussions online and the current plan is to enable it for time difference calculations, e.g
time_a - time_b
If there is a leap-second in-between it will be reflected in that. Same when adding a time and a duration.
Your example contains a leap second time which we will likely not handle because neither our underlying time representation nor Python can actually deal with these “60-second” times (there were some internal discussions on the python dev mailing list but if I remember correctly they deemed the problem not serious enough to deal with it). We’d probably just raise an error in these cases.
It might be possible to add a flag “is_leapsecond” to the UTCDateTime object and than gracefully handle these cases but this will likely bring along quite some additional complexity.
It is indeed a bit problematic but it only matters for time difference that have one or more leap seconds in between so the actual damage is likely limited. But we should somehow find a proper way to deal with it.
Please join the discussion on Github if you have some more ideas:
Cheers!
Lion