Temporal support (TC39 stage 3 proposal)

What is the problem this feature would solve?

The Temporal API is already supported by Deno and the Boa JS engine.

https://github.com/tc39/proposal-temporal

What is the feature you are proposing to solve the problem?

Implement Temporal in Bun.

What alternatives have you considered?

Slow and heavy polyfills.

See temporalio/sdk-typescript#1334 ([Feature Request] Run temporal worker in bun).

Not the same temporal

See temporalio/sdk-typescript#1334 ([Feature Request] Run temporal worker in bun).

Not the same temporal

This is embarrassing. Sorry. 😊

This would be great. It looks as though in Safari whose JavaScript engine, JavaScriptCore, Bun is using, has preview support with the useTemporal runtime flag: https://bugs.webkit.org/show_bug.cgi?id=223166 & https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#browser_compatibility

The patches contain just a stub, only 2 empty objects.

It would be great to have it
-1 dependency

Looking upstream in JSC, despite the issue showing no movement in years, I see they've got an experimental implementation of Temporal: https://github.com/search?q=repo%3AWebKit%2FWebKit%20Temporal&type=code

I wonder if Bun could enable this experimentally like Deno did with the V8 Temporal implementation 👀

@NuckChorris

@NuckChorris try BUN_JSC_useTemporal=1: https://github.com/oven-sh/WebKit/blob/50ae7bfd503f896681ca5a9b848f9822c31c4912/Source/JavaScriptCore/runtime/OptionsList.h#L620

@Jarred-Sumner

@Jarred-Sumner, isn't it only for the empty stub Temporal object? Does it enable a usable implementation?

@notramo

@notramo I would recommend running the Temporal Test262 Suite against it (if I find time this weekend I might run it and report back) but from the C++ it looks at least vaguely implemented-ish?

Implementation	Pass Rate	Execution Time	Notes
`BUN_JSC_useTemporal`	40%	0.8s
`temporal-polyfill`	88%	6s
`@js-temporal/polyfill`	84%	228s	Some >10s Duration tests

It's about 40% there... but the tests run blazing fast! The test runner README estimates ~30s to run, but Bun runs it in 0.8s on my M3.

Implementation Pass Rate Execution Time Notes

BUN_JSC_useTemporal 40% 0.8s

temporal-polyfill 88% 6s

@js-temporal/polyfill 84% 228s Some >10s Duration tests

It's about 40% there... but the tests run blazing fast! The test runner README estimates ~30s to run, but Bun runs it in 0.8s on my M3.

Wants it as much as possible sooner

Because it's really great api

nodejs/node#57128

NodeJS wants to unflag it

Yes, we'd like to unflag it in node.js but still keep it marked as experimental, at least until v8's test coverage numbers are close to 100 and v8 chooses to expose it by default without the flag.

To be fair, it isn't enabled in node.js right now either ;-) ... the fact that v8 changed their approach to require a rust dependency means that the experimental flag to enable it in node.js no longer works and we're having to step back to modify the build toolchain to include the rust dependency.

Thanks for the info, and I hope that goes well! I've been super excited about this API to be available without a polyfill. Thanks for all the hard work on making it happen 😁

A couple of days ago the temporal type definition was added to typescript (see microsoft/TypeScript#62628), while the latest typescript may not be released yet it would be cool to see this implemented in bun so that when the new typescript releases with the types for it, it would be good to go and be used

@ptomato

Here's a few updates from elsewhere in the ecosystem:

The JSC implementation of Temporal is progressing but has been moving slowly, I hear because it's hard to get Apple reviewers to review Temporal submissions. @ptomato may know more recent status.

As noted above, Chrome 144 shipped with Temporal and is passing Test262 >99%. Firefox too.

TypeScript types for Temporal will ship in TS 6.0 soon.

Node.js, as noted above, is working on their Rust toolchain so they can build V8's Rust Temporal implementation and AFAIK it's working on Linux and just landed for MacOS. AFAIK they're still working on Windows. The master issue for Node is here: nodejs/node#57127.

For JSC/Safari status you can follow https://bugs.webkit.org/show_bug.cgi?id=223166, particularly its sub-tickets (in the sidebar)

TypeScript 6.0 supports Temporal https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/#new-types-for-temporal

Nodejs enables Temporal API by default.

nodejs/node@9cae819...fc4b334

Now in Nodejs nodejs/node#61898 (comment)

@Jarred-Sumner

@Jarred-Sumner Since JavaScriptCore now enables Temporal by default (via 23eb4f85f358), I was wondering what the remaining blockers are on the Bun side.

I noticed Bun still explicitly disables it with:

Options::useTemporal() = false

and the comment:

"Upstream enabled Temporal by default; keep it off in Bun until the remaining integration work lands."

Are there any remaining Bun-specific issues that need to be resolved before Temporal can be enabled by default in Bun?

I think this would be a great addition for the 1.4.0 release.

@ptomato

Has Temporal actually been completed in JSC? @ptomato do you know?

Enable Temporal by default (#32978)

Temporal is enabled by default as of #32978, so it will be in the next canary. BUN_JSC_useTemporal=0 turns it back off.

The 40% test262 figure posted earlier in this thread (February 2025) was measured with temporal-test262-runner, so here are current numbers from the same tool at test262 de8e621c, with Node v26.3.0 (which also ships Temporal by default) for comparison:

Suite	Tests	Bun	Node 26.3
`built-ins/Temporal` (core spec)	4603	100%	98.7%
`intl402/Temporal` (non-ISO calendars)	2029	56.2%	38.3%
`intl402` `DateTimeFormat`/`DurationFormat` over Temporal objects	259	99.2%	91.9%
`built-ins/Date/prototype/toTemporalInstant`	8	100%	100%

Every test262 test where Bun trails Node (136 of them) is non-ISO calendar behavior inside intl402/Temporal; outside that set there is not one. The methodology and the rest of the evidence (a 20,500-operation deterministic output diff against Node with zero divergence on the iso8601/gregory/roc calendars and all DST disambiguation cases, a full ASAN pass with no crashes, and startup/memory measurements showing no cost) are in the #32978 description.

Known gaps, all in the upstream JavaScriptCore implementation:

Non-ISO calendar data: chinese/dangi leap-month placement disagrees with the reference on roughly 2-3% of dates, the ad/bc era aliases are rejected (ce/bce work), and .with({ era, eraYear }) fails on the indian, ethiopic, and islamic-* calendars.
dayOfYear ignores the calendar and returns the ISO ordinal: Temporal.PlainDate.from("1883-02-23").withCalendar("hebrew").dayOfYear is 54 in Bun, and 163 in Node and the reference polyfill. This affects every calendar whose year does not start on January 1, and is being filed upstream.
The buddhist calendar's year getter returns the ISO year instead of BE: .withCalendar("buddhist") on ISO 1870 gives year 1870 where Node and the reference polyfill give 2413 (eraYear is correct, so the two disagree). Also being filed upstream, with the root cause identified.
Legacy IANA zone IDs such as CET and EST5EDT are rejected by Temporal.ZonedDateTime. This is not Temporal-specific: new Date() and Intl.DateTimeFormat().resolvedOptions().timeZone already fall back to UTC for them in Bun today.

TypeScript 6.0's lib.esnext.d.ts references esnext.temporal, so types work out of the box on TS 6 with an esnext lib.

Enable Temporal by default (oven-sh#32978)

feat(shared): accept ISO 8601 durations in config timeouts

Navigation Menu

Repository navigation

Temporal support (TC39 stage 3 proposal) #15853

What is the problem this feature would solve?

What is the feature you are proposing to solve the problem?

What alternatives have you considered?

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Temporal support (TC39 stage 3 proposal) #15853

Description

What is the problem this feature would solve?

What is the feature you are proposing to solve the problem?

What alternatives have you considered?

Activity

maurovanetti commented on Jan 23, 2025

kravetsone commented on Jan 23, 2025

maurovanetti commented on Jan 23, 2025

TomasHubelbauer commented on Jan 30, 2025

notramo commented on Jan 30, 2025

kravetsone commented on Jan 30, 2025

NuckChorris commented on Feb 9, 2025

Jarred-Sumner commented on Feb 9, 2025

notramo commented on Feb 10, 2025

NuckChorris commented on Feb 13, 2025

jacksteamdev commented on Feb 18, 2025

kravetsone commented on Feb 18, 2025

kravetsone commented on Feb 18, 2025

jasnell commented on Feb 19, 2025

7 remaining items

jasnell commented on Nov 7, 2025

odicho commented on Nov 7, 2025

Astrolaxis commented on Feb 10, 2026

justingrant commented on Feb 11, 2026

ptomato commented on Feb 11, 2026

juergenzimmermann commented on Mar 26, 2026

odicho commented on Apr 14, 2026

gameroman commented on Apr 24, 2026

rubenferreira97 commented on Aug 3, 2026

justingrant commented on Aug 3, 2026

robobun commented on Aug 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions