Description
Looking at the ISO 8601 years specifics:
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 […] 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"
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.[20] 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[21] 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.[22]
Topics:
- Mutual agreement for the representation of years before 1583 (first year fully covered by the Gregorian calendar): using ISO 8601 for dates before 1583 is not allowed unless everyone parties agree it’s allowed.
- Mutual agreement needed for anything outside of the 4-digits notation, with mandatory use of the sign (event for
+
). - What to do with “year 0”? It doesn’t exist in real world but ISO 8601 says it’s actually year -1. For
new Date(-33, 0, 1).getFullYear()
, does it represent actual year -33 or actual year -34? For accuracy with date diffing, it would be nice ifdatetime-attribute
could allow to configure this behaviour (e.g. with ashiftDatesBeforeYearOne
setting or with something else that would remind the era of theTemporal.PlainDateTime
object). Currentlynew Date(-33, 0, 1)
is expected to be real year -33 (see tests).
Tasks:
- add missing
+
sign beyond 9999; - document stuff regarding “year 0”;
- decide how to enable the year shift before year 1 (check how libraries are handling that).