this post was submitted on 20 Nov 2023
1301 points (97.0% liked)

196

16238 readers
1931 users here now

Be sure to follow the rule before you head out.

Rule: You must post before you leave.

^other^ ^rules^

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 5 points 10 months ago* (last edited 10 months ago) (2 children)

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 10 months ago

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

[–] [email protected] 1 points 10 months ago* (last edited 10 months ago)
  1. A period of one day and one hour.
  2. A period of one year, ten times, from the 208th day of 2021.
  3. Ten hours and 18 minutes pm (I'm not sure about this one) on UTC+08:00 (China, for example).
  4. IDK.
  5. The 2nd day of the 30th week of 2021.
  6. Same as above, but at 22:00 in China, probably.
  7. A period of one year.
  8. IDK.