It looks to me like you copied a lot of code, doc strings, tests, etc from <https://github.com/django/django/commit/9b1cb75#diff-4db1d116f25f482278090b122e3b0028> and <https://github.com/django/django/commit/2f59e94>. I wouldn’t call it trivial. There is a BSD license for Django. Or do we have to get the relevant authors to do the Python CLA thing?

The current patch seems to allow a timezone without a colon, or even without minutes (+1100 and +11 as well as the RFC’s +11:00). Is this needed? The colon was made optional in Django in <https://code.djangoproject.com/ticket/18728>; the argument given for this just seems to be ISO 8601 alignment, nothing practical. According to <https://code.djangoproject.com/ticket/22814> Postgre SQL outputs time zones without the minutes field, but I don’t know if Python should go out of its way to support this obscure format.

RFC 3339 does not specify single digits in many places (e.g. 2016-2-1 1:0:0 is not specified). Should we also be stricter, at least for the minutes and seconds fields?

Also, is it necessary to allow the seconds field to be omitted, as in "2016-02-01 01:21"?

It seems that the “datetime” module does not support leap seconds, so if we mention RFC 3339 we should point out this inconsistency.

Victor: From my limited experiments, datetime.fromtimestamp() seems to use the round-to-even rule (not always rounding half up). Can you confirm? Maybe we should use that for consistency if it is practical. Otherwise, truncation towards zero would be the simplest.

As well as adding datetime.fromisoformat(), I think we should add similar methods to the separate date and time classes. One can parse the RFC’s full-date format fairly easily with strptime(), but not so for partial-time because of the fractional seconds.