absolutedate_to_datetime fails during leap second
During a leap second, the function absolutedate_to_datetime
fails because it tries to pass second=60
to the python datetime
constructor.
The following code:
import orekit
orekit.initVM()
from orekit.pyhelpers import setup_orekit_curdir
setup_orekit_curdir()
from org.orekit.time import TimeScalesFactory
utc = TimeScalesFactory.getUTC()
from org.orekit.time import AbsoluteDate
date_start = AbsoluteDate(2016, 12, 31, 0, 0, 0.0, utc)
date_current = date_start.shiftedBy(86400.0)
print(f'Orekit date: {date_current}')
from orekit.pyhelpers import absolutedate_to_datetime
print(f'Python date: {absolutedate_to_datetime(date_current)}')
Will provide the following output:
Orekit date: 2016-12-31T23:59:60.000
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-10-31940908fd35> in <module>
14
15 from orekit.pyhelpers import absolutedate_to_datetime
---> 16 print(f'Python date: {absolutedate_to_datetime(date_current)}')
[...]/lib/python3.7/site-packages/orekit/pyhelpers.py in absolutedate_to_datetime(orekit_absolutedate)
111 or_time.getMinute(),
112 int(math.floor(seconds)),
--> 113 int(1000000.0 * (seconds - math.floor(seconds))))
114
115
ValueError: second must be in 0..59
Leap seconds are not supported in the python datetime
module:
- https://bugs.python.org/issue23574
- https://stackoverflow.com/questions/21027639/python-datetime-not-accounting-for-leap-second-properly/21029510
- https://stackoverflow.com/questions/39686553/what-does-python-return-on-the-leap-second
Therefore we must force the second to remain in the [0,59] interval. This can lead to some side effects when computing time deltas or when indexing a pandas DataFrame with this UTC date, but as always with UTC scale, the user should be careful when handling UTC dates during a leap second. To ensure that the time flow stays monotonic, I would force the second to stay at 59.999999 during a leap second.