4 ms·

> It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59"

> It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", [...] included in neither. ISO 8601 does allow for that format given a mutual agreement. The "mutual agreement" sounds serious but means nothing more than a simple qualifier like "ISO 8601 where `T` can be replaced with a space" (RFC 3339 also does this in a much wordy way). I don't think how this makes things unclear, esepcially when people generally are unaware of ISO 8601 anyway. > [...] which is by far most used DT format (because it's fucking obvious!) across all systems [...] I'm not even sure that this is the most used date-time format. The most spoken language is Chinese, for which native separators like 2023年9月1日 are common. > Also, both standards are very unclear on how to represent DTs BC, and how to represent DTs after 9999-12-31 (or before -9999-01-01), and most commonly used libraries often just cannot handle them at all. Again ISO 8601 allows for year numbers before 1582 (yes, they are not allowed by default) or after 9999 given a mutual agreement. Such numbers should be prefixed by a single sign character if it can't fit within 4 digits. They are generally not supported because we can't really do anything meaningful with that past or future date, but nevertheless I have seen enough libraries that do parse them (particularly common when they are implemented independently from C <time.h>). > And even when they can, the behavior of 00-01-01 is basically undefined (may I remind you, that Gregorian calendar is stupid, and the next year after 1 BC is 1 CE). It is defined as January 1, 1 BCE. ISO 8601 clearly states that its year number is for the proleptic Gregorian calendar, so it infinitely extrapolates back to the negative infinity.

ijmacd 3y ago
> ISO 8601 does allow for that format given a mutual agreement. ISO 8601 does not permit that format.
- lifthrasiir 3y ago
  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 https://stackoverflow.com/a/9532375 [1] Specifically the Draft International Standard that was once available from loc.gov.
  - 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 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.
euroderf 3y ago
Replace "T" with a "_", so it does not break across lines, while providing better visual separation of the date and time portions.

ijmacd 3y ago

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

lifthrasiir 3y ago
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 https://stackoverflow.com/a/9532375 [1] Specifically the Draft International Standard that was once available from loc.gov.
- 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 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.

euroderf 3y ago

Replace "T" with a "_", so it does not break across lines, while providing better visual separation of the date and time portions.