+Peter, since he has an interest in these issues. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* **
On Wed, Sep 12, 2012 at 9:37 PM, Mark Davis ☕ <[email protected]> wrote: > > > Mark <https://plus.google.com/114199149796022210033> > * > * > *— Il meglio è l’inimico del bene —* > ** > > > > On Wed, Sep 12, 2012 at 8:43 PM, Norbert Lindenberg < > [email protected]> wrote: > >> 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 problem is that the date when countries shifted to using Gregorian as > the primary calendar varies wildly. And it wasn't just from the Julian > calendar; in non-Christian countries, it was from many others (often still > in use as a secondary calendar). And historically, there were transitions > between those calendars. And not everyone in the same country followed the > same calendar, or switched at the same time. And even on the Julian > calendar, before 525 AD there wasn't the practice of using AD; you'd have > to have the year set to the year of the emperor (and let's not talk about > the transitions there...) > > Anyway, it typically isn't worth the trouble. It is quite customary to use > a proleptic calendar; many if not most standards do it. > > >> - The year calculation assumes that there was a year 0, while in normal >> usage the year before 1 AD is 1 BC. >> > > If the implementation supports eras, then you would have 2 AD, 1 AD, 1 BC, > 2 BC... > > If it uses negative proleptic years, then you'd have 2 AD, 1 AD, 0 AD, -1 > AD, -2 AD, ... > > I don't know that we want to have such a difference be a gating item.... > > >> 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 >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
