320164 – Immediate Full Adoption of Temporal API in Safari Stable Required
WebKit Bugzilla
Bug 320164: Immediate Full Adoption of Temporal API in Safari Stable Required
-->
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
-->
RESOLVED<br>DUPLICATE<br>of bug 223166320164
Immediate Full Adoption of Temporal API in Safari Stable Required https://bugs.webkit.org/show_bug.cgi?id=320164
Summary
Immediate Full Adoption of Temporal API in Safari Stable Required
riot.ted
Reported<br>2026-07-23 23:19:49 PDT
## SUMMARY
The Temporal API reached TC39 Stage 4 on March 11, 2026 and is now part of the ECMAScript 2026 specification. Firefox 139 shipped Temporal unflagged in May 2025. Chrome 144 and Edge 144 shipped Temporal unflagged in January 2026. Node.js 26 shipped Temporal unflagged on May 5, 2026. Deno 2.7 and later ship Temporal natively. Safari stable — across macOS, iOS, and iPadOS — has not shipped Temporal. Because every browser engine on iOS and iPadOS is required to use WebKit, Safari's non-shipping blocks the entire iOS and iPadOS ecosystem from executing the standardized Temporal API. This is unacceptable. Apple must ship Temporal in Safari stable across macOS, iOS, and iPadOS immediately and unconditionally.
## THE CORE PROBLEM
Temporal is a finalized ECMAScript 2026 feature. Every other major browser engine, Node.js, and Deno have shipped it in production. Safari has not. WebKit has been implementing Temporal since at least November 2021, when the initial `Temporal.Instant` patch landed in JavaScriptCore. More than four years of implementation work has not translated into a stable Safari shipping decision. During this entire period, every web developer targeting an Apple device must ship polyfill code that adds twenty to one hundred kilobytes gzipped to their bundles, or refuse to use Temporal at all. This is a direct and quantifiable cost imposed on every web development team on the planet, caused by a single vendor's shipping delay.
## CONCRETE EXAMPLE
A developer writing a global scheduling application in 2026 wants to correctly handle a meeting at 09:00 America/New_York on the day of a daylight saving transition. Using Temporal:
```js<br>const meeting = Temporal.ZonedDateTime.from("2026-03-08T09:00[America/New_York]");<br>const followUp = meeting.add({ hours: 24 });<br>```
In Chrome, Firefox, Edge, Node.js, and Deno this runs natively. To make the same code execute on Safari, the developer must ship the `@js-temporal/polyfill` package (~56 KB minified+gzipped) or the `temporal-polyfill` package (~20 KB gzipped), gate polyfill loading behind a `globalThis.Temporal` runtime detection check, and audit polyfill parity for every Temporal method used. Every single web developer on the planet targeting a mixed browser audience pays this cost — in bundle size, in build complexity, in test surface, and in reviewer time — solely because Safari has not shipped.
## THE COST
- Every web developer targeting Safari, iOS, or iPadOS ships polyfill code they would not otherwise need.<br>- Twenty to one hundred kilobytes of gzipped polyfill weight per site, paid by end users on every device including cellular iPhones and iPads.<br>- Additional build configuration, feature detection paths, and test surfaces to verify Temporal parity between native and polyfilled environments.<br>- Marketing sites, e-commerce, and performance-critical applications that cannot afford the polyfill weight are forced to keep using the legacy `Date` object indefinitely, delaying migration to the standardized replacement.<br>- Every code review, every onboarding session, every documentation page has to explain "why Safari needs a polyfill" for a feature that shipped in Firefox eighteen months ago and Chrome nine months ago.<br>- Users of Apple platforms receive a materially worse date-handling experience because their browser cannot execute the standardized API natively.<br>## PROPOSED SOLUTION
Ship Temporal in Safari stable across macOS, iOS, and iPadOS immediately and unconditionally. No flag. No opt-in. No "Technology Preview only" gating. Full parity with the ES2026 specification, matching the surface already shipped in Firefox 139, Chrome 144, and Edge 144. Publish a specific ship-in-stable date for the next Safari release on the WebKit blog and the Apple Developer News feed within thirty days of receipt of this notice.
## WHY EXISTING SOLUTIONS DO NOT WORK
Safari Technology Preview does not solve the problem. Technology Preview is a developer-facing pre-release channel with negligible end-user reach; shipping a feature there does not change what production Safari users can execute. Polyfills do not solve the problem — they impose the exact cost this document describes on every developer targeting Safari. Waiting for "the next major Safari release" is not a solution; it is a restatement of the failure mode that has held for four years. The...