RFC 3339, the "alternative" to ISO 8061, was extended to RFC 9957, which also allows adding interpretative tags.

Sounds like unnecessary complexification to me. What is wrong if anything with "2024-04-26"?

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.