(original) (raw)

>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()\`.

Yup.

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.

-Chris

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

Here is the PR I've submitted:

https://github.com/python/cpython/pull/4699

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
intended
as the inverse operation of :meth:\`datetime.isoformat\`
"""



what ISO8601 compatible features are not supported?

-CHB