ECMAScript Extended ISO-8601 Strings
2 points · Open discussiontc39
proposal-temporal
HTML2018–2026
tc39 / proposal-temporal
proposal-temporal
Provides standard objects and functions for working with dates and times.
35Distinct people
40Mentions
0Explicit recommenders
3.7KGitHub stars
What to know before exploring
What it is
Provides standard objects and functions for working with dates and times.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year40 dated mentions
Observed mentions: 2018-04-25 07:03:12 UTC to 2026-03-18 02:23:04 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 13 | 3 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 0 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Temporal
Provides standard objects and functions for working with dates and times.
Status
This proposal is currently Stage 4.
It will be merged into the ECMA-262 and ECMA-402 standards and this repository will be archived.
Implementation status:
SpiderMonkey/Firefox: shipped in Firefox 139 (on 2025-05-27)
V8/Chrome: shipped in Chrome 144 (on 2026-01-13)
Node.js: shipped in Node 26 (on 2026-05-05)
JavaScriptCore/Safari
Boa
GraalJS: planned to ship in GraalVM 25.1.0
Kiesel
Champions
Philipp Dunkel (@pipobscure)
Maggie Johnson-Pint (@maggiepint)
Matt Johnson-Pint (@mattjohnsonpint)
Brian Terlson (@bterlson)
Shane Carr (@sffc)
Ujjwal Sharma (@ryzokuken)
Philip Chimento (@ptomato)
Jason Williams (@jasonwilliams)
Justin Grant (@justingrant)
Overview / Motivation
Date has been a long-standing pain point in ECMAScript.
This proposes Temporal, a global Object that acts as a top-level namespace (like Math), that brings a modern date/time API to the ECMAScript language.
For a detailed breakdown of motivations, see:
Fixing JavaScript Date
Principles:
All Temporal objects are immutable.
Date values can be represented in local calendar systems (why?), but they should be convertable to and from the Proleptic Gregorian Calendar.
All time-of-day values are based on a standard 24-hour clock.
Leap seconds are not represented.
Specification Text
The specification text can be found here.
Documentation
Reference documentation and examples can be found below.
Temporal Documentation (English)
Temporal のドキュメント (Japanese) (translated a part of the English document into Japanese)
Temporal 文档 (Chinese) (translated a part of the English document into Chinese)
A cookbook to help you get started and learn the ins and outs of Temporal is available here
Polyfills
Polyfill
Repo
Status
@js-temporal/polyfill
js-temporal/temporal-polyfill
Alpha release available
temporal-polyfill
fullcalendar/temporal-polyfill
Stable release available
temporal-polyfill-lite
fabon-f/temporal-polyfill-lite
Release Candidate available
If you're working on a polyfill, please file an issue or PR so we can add yours here.
A non-production polyfill was built to validate this proposal.
This polyfill continues to live in this repo, but only for the purposes of running tests and powering the documentation "playground" as described below.
DO NOT use this polyfill in your own projects!
Instead, please use a polyfill from the table above.
Documentation Playground
When viewing the reference documentation, the non-production polyfill is automatically loaded in your browser, so you can try out Temporal by opening your browser's developer tools console.
Read the full README on GitHubWhat Hacker News says
13 sources“Temporal” is also the name of a JS Date object alternative being proposed.
https://github.com/tc39/proposal-temporal
In Temporal: open-source microservices orchestration platformFor new code, I think most JS devs have already switched to using the class syntax. Also FP in JS is alive and well if you want to avoid dealing with prototype chains altogether.
I think we can all agree the Date API sucks, but life can still be good if you just give in and include a date library. Also, there's some light at the end of the tunnel with Temporal proposal coming along [1].
Object.keys returning string[] is purely a TypeScript design decision, coming from how TypeScript chooses to model object subtyping [2].
type Foo = {
a: string
}
const keysOfFoo = (obj: Foo) => Object.keys(obj)
const foo = {a: '', b: 5}
keysOfFoo(foo)
The fact that this passes type checks is a conscious TS design decision that comes with both advantages and disadvantages. It wouldn't have to be this way; Exact types [3] could potential
Read the rest
ly be used to describe that if the type is exactly Foo, it's safe to assume Object.keys(foo) is (keyof Foo)[].
For first class tuples (and records), there's a stage 2 EcmaScript proposal coming along [4]. There's of course also the readonly [] type in TypeScript if you only need the safety of not accidentally pushing to an "immutable" array. First class language support could have nice additional features though, like strict equality.
Anyways, if these are the things you don't like about JS/TS, I don't think AssemblyScript will be the answer for you, as the goals of that language seem to be entirely different from "fixing" old JS cruft. Apart from the i32, i64 stuff I guess.
[1] https://github.com/tc39/proposal-temporal
[2] https://github.com/Microsoft/TypeScript/pull/12253#issuecomm...
[3] https://github.com/microsoft/TypeScript/issues/12936
[4] https://github.com/tc39/proposal-record-tuple
> `DateTime` should probably be split...
https://github.com/tc39/proposal-temporal
In We now consider Moment.js to be a legacy project in maintenance modeWell they actively ignored his input:
https://github.com/tc39/proposal-temporal/issues/7
https://github.com/tc39/proposal-temporal/issues/84#issuecom...
In Dates and Times in JavaScript – A New API for Dates from TC39It's a current WIP idea for the spec: https://github.com/tc39/proposal-temporal/pull/700
Figuring out a name is still part of the ongoing discussion, so this specific case of `LocalDateTime` isn't a huge deal, and I might have misrepresented things slightly in my original comment, sorry! But I do think the overall point still stands - that it might be best to just use the same names and terminology as Java does.
In Dates and Times in JavaScript – A New API for Dates from TC39I think he's referring to https://github.com/tc39/proposal-temporal/issues/707.
In Dates and Times in JavaScript – A New API for Dates from TC39I think this is a great proposal and a huge step in the right direction for JS. I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API? As far as I understand, they are generally considered a gold standard as far as datetime APIs.
Is it too Java-y that it wouldn't make sense to port to JS? Are there copyright implications?
The JS Temporal proposal _does_ as far as I can tell, share many of the underlying fundamental concepts, which is great, but then confusingly has some types, such as `LocalDateTime`, which mean the exact opposite of what they do in the well-known Java API [3].
There is still discussion going on about these details, but
from my perspective it seems like the best thing would be to just copy the Java naming conventions exactly.
[0]: https://www.joda.org/joda-time/
[1]:
Read the rest
Formatting is fine. Take a look at `Intl.DateTimeFormat`[1]. Then there is a proposal for `Temporal`[2] which will make handling a lot easier.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2]: https://github.com/tc39/proposal-temporal
In What the Hell Is a Deno?In case it wasn't immediately obvious, there's a Stage 2 tc39 proposal that was spawned from this blog post called Temporal:
https://github.com/tc39/proposal-temporal
At a glance, it does follow the same ideas as the great Joda Time library (now a part of the Java standard library), and there's currently a port of this library for JS which is quite nice:
https://github.com/js-joda/js-joda
In Fixing JavaScript's Date (2017)Proposal Temporal: Fixing dates and times in JavaScript
2 points · Open discussionOn a related note, JavaScript is getting a better date library: https://github.com/tc39/proposal-temporal.
In You don't need libraries for internationalization of dates