ES5 section 15.9.1 specifies a number of operations to map time values (measured in milliseconds from January 1, 1970, midnight UTC) to year/month/day/hour/minute/second values, and the ECMAScript Internationalization API specification section 12.3.2 mandates use of these algorithms also for formatting localized date and time strings if the Gregorian calendar is used.
A well-placed test within the SpiderMonkey test suite reminded me of two issues related to that: - The algorithms use a proleptic Gregorian calendar, that is, apply the rules of the Gregorian calendar all the way back to the beginning of ECMAScript time. Normal usage, however, is to use the Julian calendar for dates before the introduction of the Gregorian calendar in 1582 (and in some countries for quite some time after that). - The year calculation assumes that there was a year 0, while in normal usage the year before 1 AD is 1 BC. With regards to the first issue, the November 2011 draft of the spec had limited applicability of the 15.9.1 algorithms to the internationalization API to dates after 1930, but then somebody (I forgot who) convinced me to remove that limitation. I don't think the second issue has ever been discussed, and introducing a year 0 where there was none just seems wrong to me. Current implementations of Date.prototype.toLocaleString are split: Firefox, Chrome, and Opera format a date in 1 BC as being in the year 0, while Safari formats it as being in the year 1 (means BC but doesn't say so) and Explorer formats it as being in the year 1 BC. Safari calculates the day according to the Julian calendar, all others use the proleptic Gregorian calendar. Thoughts? Depending on what we decide, the beginning of ECMAScript time could be anywhere between 271816 BC and 271822 BC... Regards, Norbert _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
