python_dateutil 2.5.2 breaks parsing

[Ryan-K]

It seems that recently (3/27) there was a new version of python_dateutil released (2.5.2) that breaks parsing of strings. I'm able to work around this by pinning python_dateutil to 2.5.1.

>>> from delorean import parse
>>> parse("2015-11-25T07:24:40.504024+0000")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/appenv/local/lib/python2.7/site-packages/delorean/interface.py", line 68, in parse
    dt = capture(datetime_str, dayfirst=dayfirst, yearfirst=yearfirst)
  File "/appenv/local/lib/python2.7/site-packages/dateutil/parser.py", line 1164, in parse
    return DEFAULTPARSER.parse(timestr, **kwargs)
  File "/appenv/local/lib/python2.7/site-packages/dateutil/parser.py", line 577, in parse
    ret = default.replace(**repl)
ValueError: month must be in 1..12
>>> parse("2015-25-11T07:24:40.504024+0000")
Delorean(datetime=datetime.datetime(2015, 11, 25, 7, 24, 40, 504024), timezone='UTC')

[rupert]

python-dateutil 2.5.3 parses the above correctly.

However there's another issue with the day and month being swapped:

>>> from delorean import parse
>>> parse('2015-01-02').date
datetime.date(2015, 2, 1)
>>> parse('2015-01-13').date
datetime.date(2015, 1, 13)

Downgrading to 2.5.1 is a temporary workaround.

[rupert]

Looks like there is a bug with the dayfirst argument to dateutil.parser.parse.

In python-dateutil 2.5.1:

>>> from dateutil.parser import parse
>>> parse('2015-01-02')
datetime.datetime(2015, 1, 2, 0, 0)
>>> parse('2015-01-02', dayfirst=True)
datetime.datetime(2015, 1, 2, 0, 0)

In python-dateutil 2.5.3:

>>> from dateutil.parser import parse
>>> parse('2015-01-02')
datetime.datetime(2015, 1, 2, 0, 0)
>>> parse('2015-01-02', dayfirst=True)
datetime.datetime(2015, 2, 1, 0, 0)

dateutil bug: dateutil/dateutil#233 (comment)

[rupert]

In the latest version of dateutil (2.5.3) with dayfirst=True and yearfirst=True (the delorean defaults), XXXX-XX-XX will be parsed as YYYY-DD-MM (unless the last part is > 12 where it will be parsed as YYYY-MM-DD).

Might want to consider defaulting dayfirst=False so ISO 8601 dates are handled correctly.

[myusuf3]

@rupert any chance you want to make this switch add tests and update documentation?

[rupert]

Unfortunately I don't think you can handle ISO 8601 dates and something like DD/MM/YYYY (sensible default rather than MM/DD/YYYY) with the same datefirst argument in dateutil 2.5.3.

dayfirst=False parses ISO 8601 dates correctly but of course parses DD/MM/YYYY as MM/DD/YYYY:

>>> parse('2003-02-01', dayfirst=False)
datetime.datetime(2003, 2, 1, 0, 0)
>>> parse('01/02/2003', dayfirst=False) # wrong
datetime.datetime(2003, 1, 2, 0, 0)

dayfirst=True parses DD/MM/YYYY correctly but not ISO 8601 dates:

>>> parse('2003-02-01', dayfirst=True) # wrong
datetime.datetime(2003, 1, 2, 0, 0)
>>> parse('01/02/2003', dayfirst=True)
datetime.datetime(2003, 2, 1, 0, 0)

Possibly you could attempt to parse the date with the iso8601 library first and fallback to dateutil with dayfirst=True if that fails.

As an aside I'm actually not using delorean for parsing anymore as I think it's better to be explicit about which formats your program will accept.

This is a duplicate of #84.

[rupert]

Another option is pinning dateutil to <=2.5.1 and waiting for the new parsing interface in 2.6.

See this comment: dateutil/dateutil#229 (comment)

[myusuf3]

@rupert dateutil2.6 has been released as @gordol pointed out. Mine checking to see if it fixes the issues you name above?