>but is it that hard to parse arbitrary
ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd
like, but not THAT bad a spec.

No, and in fact this PR is adapted from a *more general* ISO-8601 parser that I wrote (which is now merged into master on python-dateutil). In the CPython PR I deliberately limited it to be the inverse of `isoformat()` for two major reasons:

1. It allows us to get something out there that everyone can agree on - not only would we have to agree on whether to support arcane ISO8601 formats like YYYY-Www-D,

I don’t know — would anyone complain about it supporting too arcane a format?

Also — “most ISO compliant “ date time strings would get us a long way.

but we also have to then discuss whether we want to be strict and disallow YYYYMM like ISO-8601 does,

Well, I think disallowing something has little utility - we really don’t want this to be a validator.

do we want fractional minute support? What about different variations (we're already supporting replacing T with any character in `.isoformat()` and outputting time zones in the form hh:mm:ss, so what other non-compliant variations do we want to add..

Wait — does datetime.isoformat() put out non-compliant strings?

Anyway, supporting all of what .isoformat() puts out, plus Most of iso8601 would be a great start.

 - if it comes out of `isoformat()` it should be able to go back in througuh `fromisoformat()`.


But had anyone raised objections to it being more flexible?

2. It makes it *much* easier to understand what formats are supported. You can say, "This function is for reading in dates serialized with `.isoformat()`", you *immediately* know how to create compliant dates.

We could still document that as the preferred form.

You’re writing the code, and I don’t have time to help, so by all means do what you think is best. 

But if you’ve got code that’s more flexible, I can’t imagine anyone complaining about a more flexible parser.

Though I have a limited imagination about such things. 

But I hope it will at least accept both with and without the T.

Thanks for working on this.


On 12/07/2017 08:12 PM, Chris Barker wrote:

Here is the PR I've submitted:


The contract that I'm supporting (and, I think it can be argued, the only
reasonable contract in the intial implementation) is the following:

   dtstr = dt.isoformat(*args, **kwargs)
   dt_rt = datetime.fromisoformat(dtstr)
   assert dt_rt == dt                    # The two points represent the
same absolute time
   assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None)   # And
the same wall time

that looks good.

I see this in the comments in the PR:

This does not support parsing arbitrary ISO 8601 strings - it is only
as the inverse operation of :meth:`datetime.isoformat`

what ISO8601 compatible features are not supported?