It's got its own little parsing language, different than the usual strftime/strptime format scheme, more like what you might see in Excel. I never worried too much about the speed of dateutil.parser.parse() unless I was calling it in an inner loop, but arrow.get() seems to be a fair bit faster than dateutil.parser.parse. This makes sense, as the latter tries to figure out what you've given it (you never give it a format string), while in the absence of a format string, arrow.get assumes you have an ISO-8601 date/time, with only a few small variations allowed.

Skip

On Tue, Nov 28, 2017 at 2:52 PM, Paul G <paul@ganssle.io> wrote:

IIRC, arrow usually calls dateutil to parse dates anyway, and there are many other, lighter dependencies that will parse an ISO 8601 date quickly into a datetime.datetime object.

I still think it's reasonable for the .isoformat() operation to have an inverse operation in the standard library.
On November 28, 2017 3:45:41 PM EST, Skip Montanaro <skip.montanaro@gmail.com> wrote:
 I think the latest version can now strptime offsets of the form ±HH:MM with
 %z, so there's no longer anything blocking you from parsing from all
 isoformat() outputs with strptime, provided you know which one you need.

Or just punt and install arrow:

 import arrow
 arrow.get('2017-10-20T08:20:08.986166+00:00')
<Arrow [2017-10-20T08:20:08.986166+00:00]>
 arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))

Skip