Repository navigation
Error parsing unambiguous dates #233
Description
It seems in version 2.5.2, there started being problems parsing unambiguous dates that don't follow the specified dayfirst option:
>>> import dateutil
>>> dateutil.__version__
'2.5.2'
>>> dateutil.parser.parse('2010 09 25', dayfirst=True)
Traceback (most recent call last):
File "<input>", line 1, in <module>
File "C:\Users\Chase\projects\flexget\py27\lib\site-packages\dateutil\parser.py", line 1164, in parse
return DEFAULTPARSER.parse(timestr, **kwargs)
File "C:\Users\Chase\projects\flexget\py27\lib\site-packages\dateutil\parser.py", line 577, in parse
ret = default.replace(**repl)
ValueError: month must be in 1..12In previous versions it would produce a valid date.
>>> import dateutil
>>> dateutil.__version__
'2.5.1'
>>> from dateutil import parser
>>> parser.parse('2010 09 25', dayfirst=True)
datetime.datetime(2010, 9, 25, 0, 0)Was this an intended change?
Activity
pganssle commentedon Mar 28, 2016
This was most certainly not an ambiguous change, and probably can be patched in a bugfix release. The 2.5.2 release doesn't have much in it (mainly it was just released to update the
tzdataupdate), so I suggest using the 2.5.1 release if possible until we can get out a fix.pganssle commentedon Mar 28, 2016
Note - if anyone goes to fix this before I get around to it, please work off the
2.5.xbranch, not the themasterbranch.ignore dateutil 2.5.3 due to dateutil/dateutil#233
rupert commentedon Apr 29, 2016
The fix in #234 only works when the day part of
YYYY-MM-DDis<= 12. I suppose you might want to supportYYYY-DD-MM(!) - SQL Server uses this format for some languages.In 2.5.1:
In 2.5.3:
Delorean bug: myusuf3/delorean#87
pganssle commentedon Apr 29, 2016
@rupert I'm not sure I understand the issue.
2015-01-13is unambiguously YYYY-DD-MM. No other interpretation of those values constructs a valid date. The fundamental assumption of the parser is that you gave it a valid date, and it will be as charitable as possible in interpreting that date.See my comments on #214 if you want
dayfirstoryearfirstto be strict.rupert commentedon Apr 29, 2016
Yes
2015-01-13is handled correctly, the issue is with2015-01-02being parsed asYYYY-DD-MMinstead ofYYYY-MM-DD(i.e. the 2.5.1 behaviour is correct).Day and month swapped in 2.5.3:
rupert commentedon Apr 29, 2016
To be honest this is more a problem with delorean defaulting
dayfirsttoTrue: https://github.com/myusuf3/delorean/blob/064bc8d0716e06838f11ac38fbf3e56ec63c4e76/delorean/interface.py#L15pganssle commentedon Apr 29, 2016
Just set it to
False?That is the intended behavior change for dateutil version 2.5.2 - the combination of
dayfirstandyearfirstare used to disambiguate betweenymd,ydm,dmy,mdyas the "default" order for ambiguous triplets. See #81 and #238 for more details on how these work. At some point relatively soon, I will update the documentation with the chart in #238.rupert commentedon Apr 29, 2016
Yes setting it to
Falseworks. Originally I wasn't sure if this was an intended change. Thanks for clarifiying; I'm actually now usingdateutildirectly.deloreanhas some documentation fordayfirstandyearfirstwhich needs updating. I'll add a comment to the other issue. Thanks.Update quantum self-tests to take into account changes in dateutil.