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

David Patte dpatte at relativedata.com
Thu Mar 4 21:11:09 UTC 2021

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

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

More information about the tz mailing list