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