[jnks]

How many dates are you parsing at a time that optimizing this would make a noticeable difference to users?

[evmar]

The post says: "For large object structures with thousands of date time objects this can easily add up." At 0.1ms per parse, that's 100ms per thousand dates, within the range of noticeable. (Their profiler screenshot has it taking 589ms.)

[imaginenore]

0.1ms to parse a date???

Even the standard PHP string parser does 0.017ms on my 3 year old netbook.

    <?php

    $st = microtime(true);
    $cnt = 10000;

    for ($i=0; $i<$cnt; $i++)
    	strtotime('2014-01-09T21:48:00.921000');

    echo 1000 * (microtime(true) - $st) / $cnt;

Seems like this solves a non-existing issue.

[anemitz]

You can see the issue it solves pretty clearly here: https://github.com/elasticsales/ciso8601#benchmark

Python != PHP

[imaginenore]

Actually both Python and PHP are ridiculously slow languages. Though Python is slower.

[illumen]

Some implementations of python are slowish for some tasks. Many parts, like the module being discussed are written in C/assembly/fortran/Java.

Python with a jit is Pypy, http://speed.pypy.org/

Also PHP has some fast _implementations_ of PHP.

[grinich]

Languages aren't slow. Interpreters are.

As a human, I can think a lot faster in Python. So for me, it's a faster language.

[philfreo]

This also doesn't do the same thing, since you're not constructing a DateTime object.

[easytiger]

I do notice a lot of people on hackernews who clearly have never had to write high throughput software.

Lots of people deal with data rates that make webscale throughput look pretty pathetic; you are just less likely to know as it will be prop tech