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}).
Actual programmers wondering why this joke doesn’t mention 65535…
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}).