I'm not sure I would agree with that. ISO-8601 is ambiguous, and very difficult to parse. For example, here are a couple valid ISO-8601 strings. Could you let me know what they mean?

P1DT1H
R10/2021-208/P1Y
T22.3+0800
22,3
2021-W30-2
2021-W30-2T22+08
P1Y
20

Taken from here. My favorite is the last one (20). If someone just wrote 20 and told you to parse it using ISO-8601, what would you get? Hour? It could even be century (ie. 2023%100)!!

So I would argue that ISO-8601 is just a wee bit too flexible. Personally, I like RFC 3339 just a bit more...

Edit: that said, I would definitely agree that something along the lines of 2021-07-27T14:20:32Z is better than any regularly accepted alternative, and I pretty much format my dates that way all the time.

[–] [email protected] 2 points 1 year ago

to be fair, you don't parse "20" without first passing "%C"

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

A period of one day and one hour.
A period of one year, ten times, from the 208th day of 2021.
Ten hours and 18 minutes pm (I'm not sure about this one) on UTC+08:00 (China, for example).
IDK.
The 2nd day of the 30th week of 2021.
Same as above, but at 22:00 in China, probably.
A period of one year.
IDK.

[–] [email protected] 0 points 1 year ago (2 children)

Don’t think my bank will like it if I date forms with that.

[–] [email protected] 12 points 1 year ago

Mine doesn't care. It actually never occurred to me not to.