Temporal - ECMAScript built-in JS Library for dates/times/timezones/calendars in progress
Hi 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
Jase, Why did you decide not to support leap seconds? Are there plans for a version 2 that does support leap seconds? John Sauter (JOhn_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
Thanks for the heads-up. Proposed patch attached, and installed into the development repository.
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/chron... On Thu, 4 Mar 2021 at 17:55, Jase Williams via tz <tz@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
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/chron...
On Thu, 4 Mar 2021 at 17:55, Jase Williams via tz <tz@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
FYI - this is going to be discussed at the DISPATCH session at IETF110, which is starting in a couple of hours. I didn't notice this email until just now. Cheers, Bron. On Fri, Mar 5, 2021, at 04:27, Jase Williams via tz wrote:
Hi
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
-- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com
participants (6)
-
Bron Gondwana -
David Patte -
Jase Williams -
John Sauter -
Paul Eggert -
Stephen Colebourne