ijmacd

"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 correct that previous editions allowed omission of the 'T' in DateTime expressions. ISO 8601:2004 (the most recent version before ISO 8601-1:2019) states in § 4.3.2:

> NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard.

This was removed with the 2019 version. However there is another section in the latest version which some people get caught out by. ISO 8601-1:2019 § 5.3.5 states:

> In time-only expressions, UTC of day expressions and time of day with time shift expressions, the time designator [“T”] may be omitted in the representations defined in 5.3 only when there is no risk of confusion.

This only refers to Time expressions (not DateTime) and says that both "T16:40" and "16:40" are valid time representations.

> ISO 8601 does allow for that format given a mutual agreement.

ISO 8601 does not permit that format.

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.

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.

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”, “minus” and “plus-minus”. In an environment where use is made of a character repertoire based on ISO/IEC 646, “hyphen” and “minus” should be both mapped onto “hyphen-minus”.

And as you correctly state, Unicode is based on ISO 8859 which is based on ISO 646. So it would seem the intention really is to use U+2D hyphen-minus when Unicode is the character set.

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 always requires a timezone.

So the Venn diagram wasn't wrong, but I agree it was misleading.

I've now updated the diagram to add the following format, which is valid under both standards:

    2023-09-01T02:12:07.284307Z

> 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:

    2023-09-01T09:40:01+08:00
    20230901T094001+0800