updated python-dateutil breaks unit tests and arctic/date

[bmoscon]

newest version of dateutil brings in a lot of changes in its parser, which breaks:

https://github.com/manahl/arctic/blob/master/arctic/date/_parse.py

from my initial inspection it seems that an agnostic parser is no longer possible. For example:

parse("20111231") will break everytime, because of the check with dayfirst=True:

arctic/date/_parse.py:7: in parse
    == _parse(string, dayfirst=True, **kwargs)):
../../../virtualenv/python2.7.9/lib/python2.7/site-packages/dateutil/parser.py:1164: in parse
    return DEFAULTPARSER.parse(timestr, **kwargs)
../../../virtualenv/python2.7.9/lib/python2.7/site-packages/dateutil/parser.py:577: in parse
    ret = default.replace(**repl)
E   ValueError: month must be in 1..12

I'm not sure what the past behavior was, but currently if it cannot parse a date based on the given information it now raises an error

(see these logs for more info: https://travis-ci.org/manahl/arctic/jobs/119019881 )

[bmoscon]

after looking at this a bit more, it looks unclear how to handle this:

1. enforce YYYYMMDD format. remove attempts to distinguish between ambiguous dates
2. Change the unit tests. Honestly I'm not sure how they ever worked. 20111231 with dayfirst = True? How did that ever work? Either way, ambiguous dates that once worked, now no longer work.
3. Since most dates wont work with yearfirst=True and dayfirst=True, we can try and find a new way to detect date ambiguity. It seems that we can try with yearfirst and dayfirst both set and if any of them return a date (exceptions would be ignored) then we can compare those dates

@jamesblackburn

[bmoscon]

i think 2 and 3 would have to go together if you wanted to try and keep the same functionality.

consider this date:
20110102

just calling parsed gives 2011-01-02
parsed with yearfirst gives 2011-01-02
parsed with dayfirst gives 2011-02-01

[bmoscon]

Eventually I found the PR that caused this:
dateutil/dateutil#229

Looks like there was a bug before that caused all dates to default to YYYYMMDD when separators were missing.

[bmoscon]

resolved