Hacker News Reader

Comment by Negative1 | Hacker News Reader

In the same vein check out Arrow for a big improvement over Pythons standard time/date libraries. As a bonus it also generates human readable dates (though I don't think it parses them like this lib): http://crsmithdev.com/arrow/

View on HN

Except that arrow is simple-minded when trying to parse date strings (compared to dateparser or delorean[1]). By default, it only tries to match a few patterns. You'll see a lot of this:

    arrow.parser.ParserError: Could not match input to any of
    ['YYYY-MM-DD', 'YYYY-MM', 'YYYY'] on '01-06-17'

Here's a list of (US English–centric) test dates that dateparser ((ddp.get_date_data(date)['date_obj']).date()) and delorean (delorean.parse(date, dayfirst=False, yearfirst=False).date) both parse correctly, nearly all of which arrow fails on:

    01-06-2017
    01-06-17
    2017-01-06

    01/06/2017
    01/06/17
    2017/01/06

    Jan 6, 2017
    Jan 6 2017

    2017, Jan 6
    2017 Jan 6

    2017, January 6
    2017 January 6

    January 6, 2017
    January 6 2017


    January 6nd, 2017
    January 6rd, 2017
    January 6st, 2017
    January 6th, 2017

    January 6nd 2017
    January 6rd 2017
    January 6st 2017
    January 6th 2017


    2017, January 6nd
    2017, January 6rd
    2017, January 6st
    2017, January 6th

    2017 January 6nd
    2017 January 6rd
    2017 January 6st
    2017 January 6th


    01//06/2017
    01//06//2017
    01--06-2017
    01--06--2017

    01/06-2017
    01-06/2017

I like Delorean's API better than arrow's (strictly personal preference) but think dateparser's language detection is interesting.

[1] http://delorean.readthedocs.org/en/latest/quickstart.html

>01-06-17 //

What's the correct parsing of that date? Is it 2001 or 2017 or 1917 or ... is it June or January ...?

I was curious what Haskellers were using and found this:

https://github.com/codygman/git-date-haskell

Had to do a small bugfix from bitrot, but this is a nice package that wraps the git date handling code which the author claims[0] was the only sane implementation he could find.

0: http://stackoverflow.com/questions/9831956/parsing-fuzzy-dat...

Arrow is far from "production" ready with severe limitations, bugs, incompatibilities and the maintainers appear to be unresponsive. It made a big splash here, but an unwarranted one.

Reply on news.ycombinator.com