I was originally about to answer the counterevidence... But wow, you are actually correct! I don't have a copy for ISO 8601-1:2019, but 8601-1:2016 [1] has the following note in the section 4.3.2 Complete representations:
> 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.
I thought this allows a replacement of [T] with a space, but it doesn't state so! It just means that the time designator can be omitted, e.g. 2023-09-0117:12:30 instead of 2023-09-01T17:12:30. It does look very strange (especially when used with extended formats) and I'm not sure if it was actually intended or not as there is no accompanying example, but nevertheless the 2016 spec doesn't allow a space. Oops.
EDIT: It indeed seems that ISO 8601-1:2019 no longer has this note. I now agree that this is a bad move. https://stackoverflow.com/a/9532375
[1] Specifically the Draft International Standard that was once available from loc.gov.
"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.
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.
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 putting this out there and also for iterating on it! I will start using sending this to folks as a reference now that I know it's being maintained!
Ah, I see that listed as a valid ISO 8601 format in the table, but not in the visualization, so I missed it. Also I can't say I've ever seen the basic format in the wild, is there anywhere it's used regularly?
When the timestamp gets slammed into a file name, as the colon is reserved on Windows and MacOS. Also, when space matters, as it's very slightly shorter.
ISO 8601 does not permit that format.