Parse python logger timestamps

[ghost]

By default, the Python logging module uses a format that includes %(asctime)s. The Python docs define this variable as:

Human-readable time when the LogRecord was created. By default this is of the form ‘2003-07-08 16:49:45,896’ (the numbers after the comma are millisecond portion of the time).

Example: 2003-09-25 10:49:41,502

Currently, dateutil fails to parse a string like this:

>>> from dateutil.parser import parse
>>> parse("2003-09-25 10:49:41,502")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/site-packages/dateutil/parser.py", line 1008, in parse
    return DEFAULTPARSER.parse(timestr, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/dateutil/parser.py", line 395, in parse
    raise ValueError("Unknown string format")
ValueError: Unknown string format

This patch enables dateutil to parse these timestamps which are extremely common in Python log files.

>>> from dateutil.parser import parse
>>> parse("2003-09-25 10:49:41,502")
datetime.datetime(2003, 9, 25, 10, 49, 41, 502000)

[pganssle]

Thanks @ryanss. I haven't given this a thorough look-over yet, but I believe this solves Issue #28. I remember when I looked at this some months ago I found it a bit difficult to handle all the edge cases, so I'll have to see what I was thinking about at the time.

[pganssle]

@ryanss I think my previous concern was that there could be some weird edge cases where this approach could be problematic and since there isn't actually a spec saying what formats and what variations on formats we support, it's hard to say whether this could break any of it.

That said, I think the best thing to do is to take our unit tests as a de facto spec for what formats are supported, and since this doesn't break the unit tests, it's a 👍 from me.

I did make a PR (ryanss/dateutil#1) against your branch to pre-compile the regular expression. Since this tokenizer is called in the innermost loop of the parser, I think it's best to move the overhead of creating the regular expression into a static member. Let me know if you disagree.

[ghost]

Completely agree, this is much more efficient. I've updated my pull request to reflect the compiled regular expression changes.

[pganssle]

Looks good, merging.

[wimglenn]

@pganssle

It seems to ignore the year in the string, and use the current year (or the year of default if that was specified)

>>> import dateutil.parser
>>> dateutil.parser.parse("May 20,2019")
datetime.datetime(2020, 5, 20, 0, 0)

git bisected it to this logger change, specifically bc69c3f

In python-dateutil<2.5.0 the result was parsed correctly.

Any way to make dateutil throw an exception here instead?