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?
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.
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 20Taken from here. My favorite is the last one (
20). If someone just wrote20and 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:32Zis better than any regularly accepted alternative, and I pretty much format my dates that way all the time.to be fair, you don’t parse “20” without first passing “%C”