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.
On Tue, Nov 28, 2017 at 2:52 PM, Paul G email@example.com 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 < firstname.lastname@example.org> 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:
datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))