> I think we need something like this:
> 2022-11-23T08:52:02!Europe/London
There is a IETF standard proposal, which is very closed to getting finalised, that defines a similar format:
2022-11-23T08:52:02+01:00[Europe/London]
ref: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-...
It's already in use by the Temporal TC39 proposal, which defines new types for working with temporal data in JavaScript.
ref: https://github.com/tc39/proposal-temporal
In Unix time is bad and needs replacement, not UTCtc39
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
3 sourcesIf you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats).
- https://github.com/tc39/proposal-temporal
- https://github.com/tc39/proposal-temporal#polyfills
- https://tc39.es/proposal-temporal/
- https://tc39.es/proposal-temporal/docs/index.html
- https://github.com/tc39/proposal-temporal/issues/1450
- https://tc39.es/proposal-temporal/docs/parse-draft.html
As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, bu
Read the rest
t browser vendors and other implementors will start shipping it before the offical release.
This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers have asm.js / WASM support, and it goes back much farther than Temporal. Therefore with Temporal we have to consider the following:
1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1].
2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this.
3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit thi
Read the rest
s category well). The only complication I haven't quite solved yet is:
A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2]
B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3]
C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here
[0]: https://github.com/fullcalendar/temporal/blob/main/packages/...
[1]: https://github.com/tc39/proposal-temporal#polyfills
[2]: https://caniuse.com/wasm
[3]: https://caniuse.com/asmjs