Converting DDMMYYYY with dateutil.parser

Question

I have the following string input : 24052017. When I try to do:

>>>dateutil.parser.parse("24052017")

It tells me that month must be in 1..12.

I have even tried doing:

>>>dateutil.parser.parse("24052017", firstday=True)

It gives me exactly th same outcome.

What seems to happening is that it does not like the fact that there are no spaces or separators. it reads the day correctly, but when it comes to the month it reads 0520. This is what I suspect, at least.

How to I convert this specific input using dateutil.parser, without manipulating the string?

Answer 1

This format is currently not supported by dateutil. In general, if you know the format of your date and it does not have time zones, you should just use datetime.datetime.strptime to parse your dates, as dateutil.parser.parse has a considerable amount of overhead that it uses trying to figure out what format your date is in, and, critically, it may get that format wrong.

There is a pull request against the 2.6.0 branch that is under debate to add this format, you can find it here, ondateutil's github. The main argument against this would be that if you are trying to parse a series of dates, it will interpret 12052017 as "December 5, 2017", but 13052017 as "May 13, 2017". (That said, you do have the same inconsistency now in that the first date will parse to December 5, 2017, but the second date will simply fail).

If you do not know the format of the string, but you know that if it is an 8-digit numerical date you want it to be interpreted as DDMMYYYY, for now your best bet is to hard-code that exception into your parser:

from dateutil.parser import parse as duparse
from datetime import datetime

def parse(dtstr, *args, **kwargs):
    if len(dtstr) == 8 and dtstr.isnumeric():
        return datetime.strptime(dtstr, '%d%m%Y')
    else:
        return duparse(dtstr, *args, **kwargs)

There is some slow-moving planned effort to provide a more flexible and extensible parser for dateutil, but not much work has been done on this yet.