You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ksonj I'll double check the documentation, but this is basically the current expected behavior. The default parser behavior is that if an element is missing, it is replaced with the corresponding element from the default parameter. The default parameter is optional, and defaults to a timezone-naive datetime object representing midnight today's date.
Since an empty string contains no date elements, all elements are replaced with the values from the default element. The only time ValueError is raised is if the date string is malformed in some way.
I think that it might be a good idea to change this in 2.5.0, though. A date string containing no date likely qualifies as exceptional. I would think it's also particularly important when doing fuzzy date parsing, since there's no general and obvious way to tell whether the date returned came from the string or from the default, e.g.:
>>>fromdateutil.parserimportparse>>>fromdatetimeimportdatetime>>>dflt_date=datetime(2015, 03, 03)
>>>parse('What a lovely day it was.', fuzzy=True, default=dflt_date)
datetime.datetime(2015, 3, 3, 0, 0)
>>>parse('What a lovely day it was on March 3rd.', fuzzy=True, default=dflt_date)
datetime.datetime(2015, 3, 3, 0, 0)
Maybe this behavior is intended but it certainly violates the principle of least surprise.
Is this documented somewhere? I'd expect this to raise a
ValueError
.The text was updated successfully, but these errors were encountered: