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.