ijmacd

5 ms·

1.
by ijmacd 3y ago
"8601-1:2016" is not a thing. As you note there was a draft released in 2016 but was changed quite significantly before publication in 2019. That's why the LoC link isn't all that useful for settling disputes. You are co
2.
by ijmacd 3y ago
> ISO 8601 does allow for that format given a mutual agreement. ISO 8601 does not permit that format.
3.
by ijmacd 3y ago
1) There's nothing special about 6 digit years. You can also use 5, or 7 digit years, or whatever the two parties can agree to before communication starts. Part 2 of the standard gives examples of years with 10 digits.
4.
by ijmacd 3y ago
You can also use 5, or 7 digit years, or whatever the two parties can agree to before communication starts. Part 2 of the standard gives examples of years with 10 digits.
5.
by ijmacd 3y ago
That's very interesting. The relevant paragraph from the standard is in ISO 8601-1:2019 §3.2.1: > All characters used in date and time expressions and representations are part of the ISO/IEC 646 repertoire, except for “hyphen
6.
by ijmacd 3y ago
Hey thanks for pointing this out. Every time this gets posted to HN someone notices something else. The format you spotted in the Venn diagram was: 2023-09-01T10:12:07.284307 This is indeed only valid under ISO 8601 since RFC 3339
7.
by ijmacd 3y ago
> timezone is specified as 4 digits without the colon ±NNNN is valid (without colon) if used as part of the "basic" format. i.e. no hyphens or colons anywhere in the format. Thus the following are equivalent and both valid: