Calendar issues

[Mark Davis ☕]

Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Wed, Sep 12, 2012 at 8:43 PM, Norbert Lindenberg <
ecmascript at norbertlindenberg.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120912/92028442/attachment.html>