196

16430 readers

2252 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

[email protected]

1384

measuring rule (lemmy.blahaj.zone)

submitted 11 months ago by [email protected] to c/[email protected]

282 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 5 points 11 months ago* (last edited 11 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 11 months ago

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

[–] [email protected] 1 points 11 months ago* (last edited 11 months 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.