This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rdb
Recipients belopolsky, p-ganssle, rdb
Date 2019-01-25.22:15:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1548454522.74.0.92696908658.issue35829@roundup.psfhosted.org>
In-reply-to
Content
I'm a fan of "be lenient in what you accept" but I can see your point in not causing confusion about what this method is meant to be used for.

Because what I'm trying to use it for technically falls outside the intended use, I say it would make the most sense to expand the intended use a bit.  From a cursory glance at the RFC3339 spec it looks like the only other change needed to fully support RFC3339 would be to support an arbitrary number of sub-second digits, whereas fromisoformat() currently requires either exactly 3 or 6.

So, I can bundle this together with a change making it more lenient about the number of decimal places for seconds, and we can change the docs for `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those generated by isoformat()".

Does this seem acceptable?  We can always expand further to allow any ISO 8601 timestamp later, but RFC3339 would already make this function immensely more useful.  I really think that parsing RFC3339 dates is a feature Python needs to have in the standard library given their ubiquity on the web.

Alternatively I am happy to consider adding something like a utc=True flag to isoformat(), but I would personally feel reluctant to add any features that I can't think of a solid use case for.
History
Date User Action Args
2019-01-25 22:15:24rdbsetrecipients: + rdb, belopolsky, p-ganssle
2019-01-25 22:15:22rdbsetmessageid: <1548454522.74.0.92696908658.issue35829@roundup.psfhosted.org>
2019-01-25 22:15:22rdblinkissue35829 messages
2019-01-25 22:15:22rdbcreate