Calendar issues

Mark Davis ☕ mark at macchiato.com
Wed Sep 12 21:37:53 PDT 2012


+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 ☕ <mark at macchiato.com> wrote:

>
>
> 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/e4c84140/attachment.html>


More information about the es-discuss mailing list