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

Stephen Colebourne scolebourne at joda.org
Thu Mar 4 20:36:13 UTC 2021


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