Parsing of leap second gives wildly incorrect answer

[Michael Overmeyer]

I was comparing how different ISO 8601 parsing libraries handle leap seconds. While almost every one of them fail as Python's datetime doesn't have leap second support, aniso8601 doesn't fail, but gives a wildly incorrect answer.

import aniso8601

ds = u'2016-12-31T23:59:60+00:00' # last leap second, valid ISO 8601 string
aniso8601.parse_datetime(ds)

2016-12-31 00:00:00+00:00

Yields the start of the previous day (~24 hours incorrect).

Here are what other libraries do: dateutil: Error: second must be in 0..59 iso8601: Error: second must be in 0..59 isodate: Error: second must be in 0..59 arrow: Error: second must be in 0..59 ciso8601: None

[Brandon Nielsen]

Good catch! I think for now, the best I can do is error like the other libraries. Python time / datetime do not support leap seconds (see discussion here).

Depending on what the resolution of #10 winds up being, it may become possible to substitute in a leap second compatible library before parsing.

If you have a different suggestion, I'd love to hear it, otherwise I'll make it throw an exception.

[Brandon Nielsen]

Version 1.3.0 raises a ValueError when parsing a leap second:

>>> import aniso8601
>>> ds = u'2016-12-31T23:59:60+00:00'
>>> aniso8601.parse_datetime(ds)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "aniso8601/time.py", line 123, in parse_datetime
    timepart = parse_time(isotimestr)
  File "aniso8601/time.py", line 111, in parse_time
    return _parse_time_naive(timestr).replace(tzinfo=parse_timezone(tzstr))
  File "aniso8601/time.py", line 136, in _parse_time_naive
    return _resolution_map[get_time_resolution(timestr)](timestr)
  File "aniso8601/time.py", line 199, in _parse_second_time
    raise ValueError('Seconds must be less than 60.')
ValueError: Seconds must be less than 60.

I don't like it, but until aniso8601 is somehow decoupled from the Python time objects, there's not much else I can do.