3 ms·

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 represent

by 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
    > 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?! Because they are often building blocks for other standards, not necessarily to be used directly. For example there is an ISO standard called ISO/IEC 5218, "codes for the representation of human sexes", and it is simply 1 for male, 2 for female, 0 for not known and 9 for not applicable. So should the male called the sex 1? Not at all. It exists because many existing databases used such values for sexes (or genders, whatever they are). If you are not benefitting from using ISO/IEC 5218 and there is no associated legal requirement then you have no obligation to use it. Same for ISO 8601 and pretty much every standard. If you want to create a forgiving enough date and time format that aims to be adopted as much as possible, go ahead, but ISO 8601 doesn't have to do that. > [...] 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. You are correctly guessed that this description is not for everyone :-) (For example, I haven't said that it uses the Gregorian calendar.) ISO 8601 does cover that. But not everyone has to fully understand ISO 8601 to write an ISO 8601 date and time---we can just tell a (typically small) difference between the "common" format and ISO 8601. > [...] 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, [...] "ISO 8601 date and time format with the `T` omission is allowed" is a concise and complete description and not "somewhat ISO 8601". The standard explicitly says that parties can choose to pick this extension, meaning that the standard itself works well whether the extension is used or not and other defined extensions won't collide with it. This is different from something like "the format yyyy-mm-dd" for the reasons I've detailed above; it is okay as an explainer, but not enough as a specification. I do think though that ISO 8601 will benefit from explicit labels for those extensions.
Narushia 3y ago
> 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. RFC 3339 does allow the format "2023-09-20 20:30:59Z", which is more readable, although it requires either the "Z" specifier or an offset like "+00:00" at the end. From the RFC: > ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. You can also verify this with the validator on the website OP linked.

by krick 3y ago

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
  > 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?! Because they are often building blocks for other standards, not necessarily to be used directly. For example there is an ISO standard called ISO/IEC 5218, "codes for the representation of human sexes", and it is simply 1 for male, 2 for female, 0 for not known and 9 for not applicable. So should the male called the sex 1? Not at all. It exists because many existing databases used such values for sexes (or genders, whatever they are). If you are not benefitting from using ISO/IEC 5218 and there is no associated legal requirement then you have no obligation to use it. Same for ISO 8601 and pretty much every standard. If you want to create a forgiving enough date and time format that aims to be adopted as much as possible, go ahead, but ISO 8601 doesn't have to do that. > [...] 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. You are correctly guessed that this description is not for everyone :-) (For example, I haven't said that it uses the Gregorian calendar.) ISO 8601 does cover that. But not everyone has to fully understand ISO 8601 to write an ISO 8601 date and time---we can just tell a (typically small) difference between the "common" format and ISO 8601. > [...] 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, [...] "ISO 8601 date and time format with the `T` omission is allowed" is a concise and complete description and not "somewhat ISO 8601". The standard explicitly says that parties can choose to pick this extension, meaning that the standard itself works well whether the extension is used or not and other defined extensions won't collide with it. This is different from something like "the format yyyy-mm-dd" for the reasons I've detailed above; it is okay as an explainer, but not enough as a specification. I do think though that ISO 8601 will benefit from explicit labels for those extensions.

Narushia 3y ago

> 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. RFC 3339 does allow the format "2023-09-20 20:30:59Z", which is more readable, although it requires either the "Z" specifier or an offset like "+00:00" at the end. From the RFC: > ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. You can also verify this with the validator on the website OP linked.