Invalid datetime can produce partial parse. Should return None instead

I came across this silent failure when parsing a third party datetime with an unusual separator:

>>> import ciso8601

>>> ciso8601.parse_datetime('2017-05-29 17:36:00Z')
datetime.datetime(2017, 5, 29, 17, 36, tzinfo=<UTC>)

#Now for a completely invalid string
>>> print(ciso8601.parse_datetime('Completely invalid!'))
None

#Now for an out of spec string (invalid separator)
>>> ciso8601.parse_datetime('2017-05-29_17:36:00Z')
datetime.datetime(2017, 5, 29, 0, 0)

It seems that the parser sees a character that it doesn’t recognize and stops parsing?

I would have expected that if the entire string cannot be parsed, it would return None as parse_datetime does for other parse failures, not silently return a datetime without time or tzinfo.

This lead to a sneaky bug in the code.

[movermeyer]

I’m not sure what sort of PR you’d be expecting. If it were my decision (ie. my library), I think I would change it to return None for all invalid input.

If that’s what you’d like to see, I could take a shot at that. But it would be a change of behaviour, so anyone who has written code that relies on this behaviour would need to change their code.

As an example of usage that would change, this test would change to expect None

[thomasst]

Thanks for this. Having both parse_datetime and parse_datetime_as_naive as you described sounds good to me!