You can see the discussion in bpo-15873 for the full rationale of why "Z" was omitted - to quote from https://bugs.python.org/issue15873#msg307607 :

> We can have further discussion later about what exactly should be supported in Python 3.8,
> but even in the pre-release discussions I'm already seeing pushback about some of the more
> unusual 8601 formats, and it's a *lot* easier to explain (in documentation) that `fromisoformat()`
> is intended to be the inverse of `isoformat()` than it is to explain which variations of ISO 8601
> are and are not supported (fractional minutes? if you're following the standard, the separator has
> to be a T, so what other variations of the standard are allowed?)

With the current implementation, the contract of the function is very simple to explain: datetime.fromisoformat() is the inverse operation of datetime.isoformat(), which is to say that every valid input to datetime.fromisoformat() is a possible output of datetime.isoformat(), and every possible output of datetime.isoformat() is a valid input to datetime.fromisoformat().

With that as the background - fromisoformat() was designed to be a conservative API because scope is a one-way ratchet, and it's better to under-commit than over-commit. We do have the option going forward of widening the scope of the function in a backwards-compatible way. The main problem I see is that I think we should maintain the property that it should be dead simple to explain what a function does, and having to enumerate edge cases is a code smell. So "it is the inverse operation of fromisoformat(), but it also supports specifying using Z for UTC" fails that test in my opinion.

I see a few rational choices here:

1. Supports the full ISO 8601 datetime spec and all outputs from datetime.isoformat() (these inputs mostly but not completely overlap). We would then just have to decide on a simple policy for how to deal with the optional portions of the spec.

2. Support only the rfc3339 standard + the outputs of datetime.isoformat(), with the option to switch to #1 later.

3. Add the ability for `datetime.isoformat()` to output 'Z' instead of `00:00`, which would allow us to support it as an input and also keep the scope of `datetime.fromisoformat` unchanged.

4. Add a separate function (either a classmethod or a bare function) for parsing exactly the ISO 8601 standard, maybe `parse_iso8601`, so both `parse_iso8601` and `fromisoformat` have a clean, rational explanation for what they do.

5. Leave the current scope alone and don't add anything.

5a. Leave the current scope alone and point people in the direction of `dateutil.parser.isoparse` in the documentation.