[tz] Temporal - ECMAScript built-in JS Library for dates/times/timezones/calendars in progress

[David Patte]

After working extensively with date-time representations, I have to 
agree with Stephen. Calendars are localization, especially in historical 
contexts.

On 2021-03-04 15:36, Stephen Colebourne via tz wrote:
> Unfortunately, this API has fallen into the same trap that Joda-Time
> did 20 years ago (one that I fixed with java.time.* [1]). It includes
> the calendar system as a property of the date, thus the date object is
> year-month-day-calendarSystem. This is a terrible design, because it
> means anyone receiving an instance needs to check that the calendar
> system is the one they expect it to be before performing any
> operations. Invariably, no developer ever does this, thus most code is
> vulnerable to bugs. For example, it is almost never the case that
> business logic should be calendar system dependent - if I borrow a
> library book for a month, it always refers to a "standard" ISO month.
> It does not refer to a Coptic month simply because the user is from
> Egypt. Calendar systems are a localization feature, not part of the
> value type.
>
> I understand TC39 feels they have to be fully internationalized, but
> this is absolutely the wrong way to do it. (And I've fed this back to
> the TC39 designers before, but there seems to be quite a bit of NIH).
>
> In my view, the API needs to go back and completely rethink this basic
> aspect of the design before it is too late.
>
> The API is also determined to use its own terminology resulting in
> cross-language confusion, rather than using the "local" terminology
> laid out in ISO-8601 over 20 years ago (mostly I understand because
> one group in Google took offence to the ISO-8601 terminology).
>
> Stephen Colebourne
> Author, Joda-Time, java.time.*
>
> [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/chrono/ChronoLocalDate.html
>
>
> On Thu, 4 Mar 2021 at 17:55, Jase Williams via tz <tz at iana.org> wrote:
>> I'm one of the TC39 (EcmaScript) delegates.
>> As a heads up to anyone interested, we're creating a new built-in module in JavaScript (to hopefully replace Date()) called Temporal.
>> This new, rich API includes:
>>
>> - First-class support for all time zones, including DST-safe arithmetic
>> - Strongly-typed objects for dates, times, date/time values, year/month values, month/year values, "zoned" date/time values, and durations
>> - Immutability for all Temporal objects
>> - String serialization and interoperability via standardized formats
>> - Compliance with industry standards like ISO 8601, RFC 3339, and RFC5545 (iCalendar)
>> - Full support for non-Gregorian calendars
>>
>> Feel free to play around with it and offer feedback on the repo.
>>
>> The repository is here:
>> https://github.com/tc39/proposal-temporal
>>
>> Documentation here:
>> https://tc39.es/proposal-temporal/docs/index.html
>>
>> Polyfill here:
>> https://github.com/tc39/proposal-temporal/tree/main/polyfill
>>
>> EcmaScript spec:
>> https://tc39.es/proposal-temporal/
>>
>> It's currently Stage 2 which means it's under review, but there's hope to see this implemented in Browsers/NodeJS soon.
>>
>> For consideration in tz-link.html. Feel free to adjust wording
>>
>> Project: https://github.com/tc39/proposal-temporal
>> NPM: https://www.npmjs.com/package/proposal-temporal
>>
>> Thanks
>> Jason Williams