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",

by krick 3y ago

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", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. 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. 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). In short, basically no software except for specialized astronomical software handles anything beyond near-future unix-time, even though for most purposes (like, uniformly representing DOB/DOD of Emperor Augustus) it's really not rocket science (we are really ok with just storing strings) and just needs to be clearly defined in some standard!

Zuiii 3y ago
> 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", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. It's much readable too. I recently started ignoring both standards in favor of the nicer space-separated format after almost two decades of sticking with the former. I get why they needed a non-whitespace character but they could have at least used an underscore or a dot. And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits. It's a string!
- krick 3y ago
  Yes, that's what I mean by "obvious". And I mean to say that it's REALLY important IMO. The point of having a standard is to abandon ALL other ways of representing a DT (or at least go as far as possible in that direction). RFC 3339 and ISO 8601 make that basically impossible. Most of your coworkers (let alone non-technical business people) don't give a damn (or even know anything, really) about standards and will represent DTs differently in different places. I can force them to use 2023-09-20 instead of 2023/09/20, and MAYBE even instead of mind-boggling USA-ian format of 09/20/2023, but I sure as hell cannot force them to use "2023-09-20T20:30:59" instead of "2023-09-20 20:30:59". Because it's less readable, and it's not arguable. > And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits No, there are reasons. People often represent year with 2 digits, so forcing you to use 4 digits is basically intended to make representing 20 CE unambiguous as 0020-01-01 (as opposed to 20-01-01). But, I mean, it's a problem to be mindful of when making a standard, not an insurmountable obstacle. A real standard to end other formats once and for all just needs to make sure to take care of all corner-cases. The truth is RFC 3339 and ISO 8601 are just shitty standards. (Edit: Also, just in case, note that it is possible to use 5 or more digits in ISO 8601. But the standard says that the parties must agree beforehand on that. That's what I mean by "unclear". I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. In the end we must to agree on how our systems will behave when receiving this or that value anyway, so it makes having an external "standard" pretty pointless, since the standard is pretty clear about very obvious situations, and very hand-wavy in all actually non-trivial situations.)
  - lifthrasiir 3y ago
    > People often represent year with 2 digits [...] Ambiguously. I've seen a lot of different cutoffs, including 1930, 1950, 1970 and 1980. And those cutoffs don't actually exist in the human conversation: I would guess the century, and if something sounds off, I'll ask the exact year number and get corrected or verified. Computers can't do that (or at least, should only do in the frontend). > I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. Laypersons have no idea what the heck is ISO 8601 anyway. I'd just say: use the format "yyyy-mm-dd hh:mm:ss", padded with enough zeros. Then I'll parse it as if ISO 8601 date and time format with the `T` omission is allowed (because it essentially is). Done. I wouldn't ever try to figure out the meaning of, say, `23-09-01 12:34:56` because they are ambiguous and should have been discouraged after all (or more practically, allow a free-form format but give the guessed normalized date and time in ISO 8601 immediately so that it can be checked).
    - krick 3y ago
      > Laypersons have no idea what the heck is ISO 8601 anyway Damn, that's a great point for sure. Then what's the point of having a standard if "nobody has any idea" what it is and and you are supposed to define all the details of the format with all corner-cases in a private conversation anyway?! That's right, there's none. The whole point of having a standard is that I can say that the value is "ISO 3166-1 alpha-2" country code, and you know that you MUST recognize all officially assigned values (or you don't really implement the protocol) AND that you'll never receive, say YY, unless ISO assigns it a value (or it would mean I violate the protocol). Now, just to be clear: this standard is also not as well-defined, as I'd like it to be — since some values can be user-assigned, and in effect 2 different implementations of "ISO 3166-1 alpha-2" can be incompatible. And I don't really see the point of referring to a changing standard without specifying a version. But it's as good as it gets here, and is totally enough for 99% of cases where you'd need country codes. ISO 8601 is way worse, since it doesn't unambiguously cover even relatively basic use-cases of how people use dates, and in effect we have lots of "somewhat ISO 8601" protocol implementations that are incompatible, and it cannot be clearly communicated what is the actual scope of your implementation by linking a sub-standard, and in the end you have to "just say": use the format "yyyy-mm-dd hh:mm:ss", padded with enough (what does "enough" mean, by the way? no clue) zeros. I.e., you have to not to refer to any standard at all. And given ISO 8601 is also clumsy as hell, most people prefer to use home-baked format anyway.
lifthrasiir 3y ago
> 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.

by krick 3y ago

Zuiii 3y ago

> 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", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. It's much readable too. I recently started ignoring both standards in favor of the nicer space-separated format after almost two decades of sticking with the former. I get why they needed a non-whitespace character but they could have at least used an underscore or a dot. And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits. It's a string!

krick 3y ago
Yes, that's what I mean by "obvious". And I mean to say that it's REALLY important IMO. The point of having a standard is to abandon ALL other ways of representing a DT (or at least go as far as possible in that direction). RFC 3339 and ISO 8601 make that basically impossible. Most of your coworkers (let alone non-technical business people) don't give a damn (or even know anything, really) about standards and will represent DTs differently in different places. I can force them to use 2023-09-20 instead of 2023/09/20, and MAYBE even instead of mind-boggling USA-ian format of 09/20/2023, but I sure as hell cannot force them to use "2023-09-20T20:30:59" instead of "2023-09-20 20:30:59". Because it's less readable, and it's not arguable. > And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits No, there are reasons. People often represent year with 2 digits, so forcing you to use 4 digits is basically intended to make representing 20 CE unambiguous as 0020-01-01 (as opposed to 20-01-01). But, I mean, it's a problem to be mindful of when making a standard, not an insurmountable obstacle. A real standard to end other formats once and for all just needs to make sure to take care of all corner-cases. The truth is RFC 3339 and ISO 8601 are just shitty standards. (Edit: Also, just in case, note that it is possible to use 5 or more digits in ISO 8601. But the standard says that the parties must agree beforehand on that. That's what I mean by "unclear". I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. In the end we must to agree on how our systems will behave when receiving this or that value anyway, so it makes having an external "standard" pretty pointless, since the standard is pretty clear about very obvious situations, and very hand-wavy in all actually non-trivial situations.)
- lifthrasiir 3y ago
  > People often represent year with 2 digits [...] Ambiguously. I've seen a lot of different cutoffs, including 1930, 1950, 1970 and 1980. And those cutoffs don't actually exist in the human conversation: I would guess the century, and if something sounds off, I'll ask the exact year number and get corrected or verified. Computers can't do that (or at least, should only do in the frontend). > I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. Laypersons have no idea what the heck is ISO 8601 anyway. I'd just say: use the format "yyyy-mm-dd hh:mm:ss", padded with enough zeros. Then I'll parse it as if ISO 8601 date and time format with the `T` omission is allowed (because it essentially is). Done. I wouldn't ever try to figure out the meaning of, say, `23-09-01 12:34:56` because they are ambiguous and should have been discouraged after all (or more practically, allow a free-form format but give the guessed normalized date and time in ISO 8601 immediately so that it can be checked).
  - krick 3y ago
    > Laypersons have no idea what the heck is ISO 8601 anyway Damn, that's a great point for sure. Then what's the point of having a standard if "nobody has any idea" what it is and and you are supposed to define all the details of the format with all corner-cases in a private conversation anyway?! That's right, there's none. The whole point of having a standard is that I can say that the value is "ISO 3166-1 alpha-2" country code, and you know that you MUST recognize all officially assigned values (or you don't really implement the protocol) AND that you'll never receive, say YY, unless ISO assigns it a value (or it would mean I violate the protocol). Now, just to be clear: this standard is also not as well-defined, as I'd like it to be — since some values can be user-assigned, and in effect 2 different implementations of "ISO 3166-1 alpha-2" can be incompatible. And I don't really see the point of referring to a changing standard without specifying a version. But it's as good as it gets here, and is totally enough for 99% of cases where you'd need country codes. ISO 8601 is way worse, since it doesn't unambiguously cover even relatively basic use-cases of how people use dates, and in effect we have lots of "somewhat ISO 8601" protocol implementations that are incompatible, and it cannot be clearly communicated what is the actual scope of your implementation by linking a sub-standard, and in the end you have to "just say": use the format "yyyy-mm-dd hh:mm:ss", padded with enough (what does "enough" mean, by the way? no clue) zeros. I.e., you have to not to refer to any standard at all. And given ISO 8601 is also clumsy as hell, most people prefer to use home-baked format anyway.

lifthrasiir 3y ago

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