3 ms·

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

by 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.
- krick 3y ago
  > ISO/IEC 5218 Look… How often are you referred to ISO/IEC 5218 standard, honestly? Me — it very well might be that you're my first. But it's nice it's there. If it wasn't, I wouldn't be very sad, because M/F/None was probably enough for me so far (and is actually way more permissive than most of actual protocols where I had to specify human sex, which usually allow just M/F). ISO 8601 on the other hand… First off, datetimes are everywhere, and are used constantly. Second, datetimes are far less trivial, and it actually requires some good amount of thinking to come up with a good representation. It is even more complicated to communicate that specification in all of the details. So, forget about whether ISO 8601 exists or not — the fact is, that I need a datetime standard. I need it every day, many times a day. Everyone needs it. Everyone comes up with his own shitty standard at least a couple of times during his life. Nobody can really communicate his own shitty standard unambiguously, covering even most popular corner cases, because only very rare people actually thought about the problem half as much, as it has to be thinked about to come up with something remotely good. And since pretty much everyone even acquainted with a notion of "standard" regards ISO as the "standards organization" we end up referring each other to ISO 8601 often enough that I know what one is talking about without actually googling the code. Technical people almost consider it a virtue of not coming up with their own standard, if there already is a usable one (and for a good reason). Long way short: ISO 8601 is important. Way more important than ISO/IEC 5218 or some meme tea-making manual. And it doesn't live up to what is (and, my point — should be) expected of it. The range of what HTML allows is far more used in practice, in my experience. Which is kinda sad, because "HTML date format" isn't really format I should be referring to, ever, it's ambiguous, it's not commonly recognized, and it doesn't even account for a number of very important use cases ISO 8601 accounts for (date ranges, for one). Now, I'm not sure which part of your post would I quote, but basically you are missing my point in the whole second half of your post. You are spending a lot of time talking about "T vs space" (which, unfortunately, might require that much time talking about and more), while this is really the trivial thing, everyone would get on the go, since it's so commonly used. So, because it's so intuitive, it's the part of the problem that begs about being standardized the least. What really begs for a standard are all these less obvious situations: 2-digit years, years before 1582, years BC, years after 9999 — which, unfortunately, are really not that uncommon. Honestly, they are common, even. And while — as I said from the very beginning — ISO 8601 does make some half-assed attempts to address all these issues, in practice it doesn't communicate any of possible scopes of values clearly enough. In effect, there are lots of applications, that pretend that they "parse ISO 8601 datetimes", yet you'll find out that, say, Python standard library just doesn't handle negative dates at all. Which is ok (I mean, bad, but understandable), but the problem is that you really have to think about it yourself to even find it out. And the big value proposition of having a standard is exactly that you don't have to think about all the details, you just rely on the fact that Wikipedia (a big, reputable project) claims that it uses standard X for the datetimes, and Python (a big, reputable project) claims that it's standard library function can parse standard X datetimes, and you just assume that someone did all the thinking for you already and they are compatible. And ideally there should be standard Y such that it makes it trivial to refer to X = Y-1 and X = Y-2 and see that they are, in fact, incompatible. So in practice ISO 8601 just doesn't do what it should.

by krick 3y ago

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.

krick 3y ago
> ISO/IEC 5218 Look… How often are you referred to ISO/IEC 5218 standard, honestly? Me — it very well might be that you're my first. But it's nice it's there. If it wasn't, I wouldn't be very sad, because M/F/None was probably enough for me so far (and is actually way more permissive than most of actual protocols where I had to specify human sex, which usually allow just M/F). ISO 8601 on the other hand… First off, datetimes are everywhere, and are used constantly. Second, datetimes are far less trivial, and it actually requires some good amount of thinking to come up with a good representation. It is even more complicated to communicate that specification in all of the details. So, forget about whether ISO 8601 exists or not — the fact is, that I need a datetime standard. I need it every day, many times a day. Everyone needs it. Everyone comes up with his own shitty standard at least a couple of times during his life. Nobody can really communicate his own shitty standard unambiguously, covering even most popular corner cases, because only very rare people actually thought about the problem half as much, as it has to be thinked about to come up with something remotely good. And since pretty much everyone even acquainted with a notion of "standard" regards ISO as the "standards organization" we end up referring each other to ISO 8601 often enough that I know what one is talking about without actually googling the code. Technical people almost consider it a virtue of not coming up with their own standard, if there already is a usable one (and for a good reason). Long way short: ISO 8601 is important. Way more important than ISO/IEC 5218 or some meme tea-making manual. And it doesn't live up to what is (and, my point — should be) expected of it. The range of what HTML allows is far more used in practice, in my experience. Which is kinda sad, because "HTML date format" isn't really format I should be referring to, ever, it's ambiguous, it's not commonly recognized, and it doesn't even account for a number of very important use cases ISO 8601 accounts for (date ranges, for one). Now, I'm not sure which part of your post would I quote, but basically you are missing my point in the whole second half of your post. You are spending a lot of time talking about "T vs space" (which, unfortunately, might require that much time talking about and more), while this is really the trivial thing, everyone would get on the go, since it's so commonly used. So, because it's so intuitive, it's the part of the problem that begs about being standardized the least. What really begs for a standard are all these less obvious situations: 2-digit years, years before 1582, years BC, years after 9999 — which, unfortunately, are really not that uncommon. Honestly, they are common, even. And while — as I said from the very beginning — ISO 8601 does make some half-assed attempts to address all these issues, in practice it doesn't communicate any of possible scopes of values clearly enough. In effect, there are lots of applications, that pretend that they "parse ISO 8601 datetimes", yet you'll find out that, say, Python standard library just doesn't handle negative dates at all. Which is ok (I mean, bad, but understandable), but the problem is that you really have to think about it yourself to even find it out. And the big value proposition of having a standard is exactly that you don't have to think about all the details, you just rely on the fact that Wikipedia (a big, reputable project) claims that it uses standard X for the datetimes, and Python (a big, reputable project) claims that it's standard library function can parse standard X datetimes, and you just assume that someone did all the thinking for you already and they are compatible. And ideally there should be standard Y such that it makes it trivial to refer to X = Y-1 and X = Y-2 and see that they are, in fact, incompatible. So in practice ISO 8601 just doesn't do what it should.