While not strictly ISO 8601, it's closely related. RFC 3339 was/is basically a subset of ISO 8601, allowing only what's strictly "needed" or really universal: e.g. 2024-05-27, 2024-03-13 12:34:56Z, etc., nothing like 2018-W06-1 or 2018-036.
Now what's really interesting is how additional data for timestamps was added. For example, specifying the human-readable timezone name, instead of just the UTC offset: 2022-07-08T00:14:07Z[Europe/Paris].

publicado de forma cruzada desde: https://lemmy.world/post/9470764

• ISO 8601 is paywalled
• RFC allows a space instead of a T (e.g. 2020-12-09 16:09:...) which is nicer to read.

I've seen the Wikipedia article on year 9 doesn't mention anything of relevance happening during November. Closest thing seems to be September. Since people around have spent a few years making lots of ruckus about how the date with "9, 11" has some sort of importance as a date, I was wondering if I'm missing something here.

Basically title. 2019 edition of the Standard denotes the "T" prefix to time as mandatory (except in "unambiguous contexts"):

01:29:59 is now actually T01:29:59, with the former form now designated as an alternative

But date does not have a "D" prefix, not even in "ambiguous contexts".

1973-09-11 never needs to be something like eg.: D1973-09-11

Anyone know the reasoning behind this change and what is the intended use? The only time-only format with separators that I can think would be undecidable in ambiguous contexts would be hh:mm which I guess could be mistaken for bible verses?

I mean, it's the obvious choice. So why not? Maybe we can do with the zoom on the cat if there is a better version.