ISO 8601 prescribes, as a minimum, a four-digit year [YYYY] to avoid the year 2000 problem. It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD, similar to astronomical year numbering. However, years before 1583 (the first full year following the introduction of the Gregorian calendar) are not automatically allowed by the standard. Instead, the standard states that “values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange”.[20]
To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[21] An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[22] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[23]
If you’re being handed a string 2022424-12-19T14:44:39Z, and told it’s ISO-8601, you should be able to figure it out. Really, a decent parser should be able to recognize that on its own (just use {4,} instead of {4} in regex). It does mean that non-hyphenated YYYYMMDD shouldn’t be used (I typically never see them encoded that way) - but even if you did, you’d just do (\d{4,})(\d{2})(\d(2}).
I get your point, but in the same way that people “shouldn’t” have been using two digits for year storage, there are certainly many parsers of ISO 8601 that don’t match the spec. In 8,000 years I don’t think this will be a problem though lol. I don’t think we can really perceive what technology might be like that far in the future. But, hypothetically, is year 10,000 was in a few days and this was year 9,999 I would suspect we’d see at least some problems come January.
I mean, that’s exactly what programmers in the '70s thought. That there would be no way in hell that their crap code would still be in use going onto 2000.
Thing is, copy/paste is always going to be easier than writing new code and that’s only going to get worse as chat bots start coding for us.
Actual programmers wondering how you’ve never seen anyone use ISO 8601 strings as storage.
If you’re being handed a string 2022424-12-19T14:44:39Z, and told it’s ISO-8601, you should be able to figure it out. Really, a decent parser should be able to recognize that on its own (just use {4,} instead of {4} in regex). It does mean that non-hyphenated YYYYMMDD shouldn’t be used (I typically never see them encoded that way) - but even if you did, you’d just do (\d{4,})(\d{2})(\d(2}).
I get your point, but in the same way that people “shouldn’t” have been using two digits for year storage, there are certainly many parsers of ISO 8601 that don’t match the spec. In 8,000 years I don’t think this will be a problem though lol. I don’t think we can really perceive what technology might be like that far in the future. But, hypothetically, is year 10,000 was in a few days and this was year 9,999 I would suspect we’d see at least some problems come January.
As an example, YAML 1.2 changed Boolean representation to only be case insensitive in 2009, but in 2022 people still complain about the 1.1 version. (Caveat: I don’t know if this person actually ran into a “real” problem or only a hypothetical one.)
I mean, that’s exactly what programmers in the '70s thought. That there would be no way in hell that their crap code would still be in use going onto 2000.
Thing is, copy/paste is always going to be easier than writing new code and that’s only going to get worse as chat bots start coding for us.