For a serialisation format, I like the Ts, because it sometimes makes munging data with cut and awk and so on slightly easier. I'd agree it's not a great display format, but then I don't think it's supposed to be.

Right, and it's distinctive, which sneaks type information past all the gremlins in your pipeline determined to strip away any and every bit of context they find in your data. On the whole I think it's probably for the best, but it is ugly.

It's pretty horrible. Apart from being hard to read (why pick an uppercase later that looks similar to numerals?), it only works for full dates or times or datetimes. You can't have literals for just years, or just hours, or just a a particular month. Even 10:20 is ambigious -- is that twenty past 10 (am), or 10 minutes 20 seconds past the hour, or a duration (iso also covers durations, but they are weird and clunky)?

Compare 2020-7-29T19:45 to Chinese style:

2020年7月29日19時45分

Easier to read and you can pick any subset of components unambiguously.

ISO-8601 allows replacing the T with a space, which transforms it from a strange format to a great one.

The T-form is still useful for filenames and the like

ISO-8601 does not allow replacing the T with a space. You are thinking of RFC 3339 “Date and Time on the Internet: Timestamps”, a profile of ISO-8601 that does allow replacing the T with a space.

From https://tools.ietf.org/html/rfc3339#page-8:

> NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.

See https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_tim... for more references.