this post was submitted on 20 Nov 2023
1387 points (99.9% liked)
196
17588 readers
665 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
Other rules
Behavior rules:
- No bigotry (transphobia, racism, etc…)
- No genocide denial
- No support for authoritarian behaviour (incl. Tankies)
- No namecalling
- Accounts from lemmygrad.ml, threads.net, or hexbear.net are held to higher standards
- Other things seen as cleary bad
Posting rules:
- No AI generated content (DALL-E etc…)
- No advertisements
- No gore / violence
- Mutual aid posts are not allowed
NSFW: NSFW content is permitted but it must be tagged and have content warnings. Anything that doesn't adhere to this will be removed. Content warnings should be added like: [penis], [explicit description of sex]. Non-sexualized breasts of any gender are not considered inappropriate and therefore do not need to be blurred/tagged.
If you have any questions, feel free to contact us on our matrix channel or email.
Other 196's:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 wrote20
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.to be fair, you don't parse "20" without first passing "%C"