Sarah Chen
Why Safari's silence matters more than Chrome's launch
Chrome 144 shipped Temporal on January 13, 2026. The internet celebrated. "JavaScript dates are finally fixed!" echoed across Hacker News and dev Twitter.
Here's the thing though: your iOS users—54% of the US mobile market—can't use it.
Safari has Temporal in Technical Preview behind a useTemporal flag. No stable release. No timeline. Apple's changelog says nothing. The TC39 proposal hit Stage 4 (fully standardized) in March 2024. Firefox shipped it in May 2025 (v139). Chrome followed in January 2026 (v144).
Safari? Radio silence.
According to Can I Use, Temporal covers exactly 49.47% of global users as of February 2026. That's Chrome 144+ and Firefox 139+. The other 50.53%? They're waiting on Safari.
This isn't new. Safari delayed CSS Container Queries 18 months after Chrome (March 2022 vs. September 2023). Scroll-driven Animations? Chrome shipped in August 2023. Safari still doesn't support them in 2026.
The numbers speak for themselves: if you ship Temporal natively today, half your users get a broken experience. If you polyfill it, you're adding ~300KB to your bundle—more than the moment.js Google told you to remove.
What Temporal actually fixes (and what it costs you)
Temporal solves real problems. Let me break this down:
Native immutability. Date mutates objects, causing silent bugs:
// Date (mutable - DANGER)
const date = new Date('2026-02-12');
date.setMonth(3); // Mutates original object
console.log(date); // Now April, not February
// Temporal (immutable - SAFE)
const date = Temporal.PlainDate.from('2026-02-12');
const april = date.with({ month: 4 }); // Returns new object
console.log(date); // Still February
Timezone-aware by default. Date mixes local time with UTC, causing off-by-one-hour DST bugs:
// Date (naive - ignores DST)
const date = new Date('2026-03-08T02:30:00'); // Hour that doesn't exist in DST
// JavaScript invents an incorrect time
// Temporal (correct)
const zoned = Temporal.ZonedDateTime.from({
timeZone: 'America/New_York',
year: 2026, month: 3, day: 8,
hour: 2, minute: 30
}); // Throws error: ambiguous hour due to DST
Nanosecond precision. Date uses milliseconds. Temporal.Instant uses nanoseconds (1000x better). Critical for:
- High-frequency financial trading
- Distributed system logs
- Real-time event timestamps
Use-case-specific API. Instead of one Date that does everything poorly:
Temporal.PlainDatefor calendars (no time)Temporal.PlainTimefor schedules (no date)Temporal.ZonedDateTimefor events with timezoneTemporal.Instantfor absolute timestampsTemporal.Durationfor measuring intervals
The catch? You pay for this with bundle size (if you polyfill) or user coverage (if you don't).
Pro tip: if your app is Chrome-only (internal tools, admin dashboards), Temporal is viable today. But if you have iOS users, the math changes.
The TC39 compromise nobody talks about
In June 2024, at the TC39 meeting in Helsinki, Philip Chimento and Justin Grant presented a controversial "scope reduction": remove customizable Temporal.Calendar and Temporal.TimeZone.
The official reason? Bundle size on Android low-end and Apple Watch. Implementers (Google, Apple, Mozilla) reported that supporting custom calendars and timezones added too much weight to the JavaScript engine.
Who does this affect?
- Companies needing custom fiscal calendars (fiscal years that don't align with January-December)
- Religious apps requiring non-Gregorian lunar calendars
- Systems using custom timezones not recognized by IANA
The original 2017 proposal allowed developers to create their own calendars and timezones. That functionality died in 2024. Implementers wanted to reduce complexity.
According to GitHub issue #2854, several contributors protested: "This turns Temporal into 90% of what we promised, not 100%." But the decision was final.
Result: Temporal supports Gregorian, Japanese, Islamic, Chinese, Hebrew, Indian, Buddhist calendars—but only the built-in ones. If your company needs a custom fiscal calendar, you're out of luck.
Real talk: this was the right trade-off. Supporting arbitrary custom calendars would've delayed Temporal another 2-3 years. The 90% solution ships; the 100% solution doesn't.
Your decision tree: polyfill debt vs. feature wait
Here's your practical decision in February 2026.
Option 1: Polyfill now
- Add
@js-temporal/polyfill(~300KB) - Works in all browsers including Safari
- Pay bundle size cost for 50.53% without native support
- Cover iOS (54% of US mobile market)
- Ship today
Option 2: Wait for Safari
- Don't polyfill
- Use Temporal only in Chrome/Firefox
- App breaks for half your users
- Unknown timeline (Apple won't communicate roadmap)
- Risk Safari takes until 2028 based on historical patterns
Option 3: Stick with date-fns
- 49 million weekly downloads
- ~80KB in typical bundles (tree-shakeable)
- Works cross-browser TODAY without polyfills
- Immutable, functional, battle-tested API since 2016
- No Safari waiting game
Here's what this actually means for your workflow:
If you're shipping consumer-facing apps (e-commerce, social, content), date-fns is the safer bet until Can I Use shows >80% coverage. The 300KB polyfill negates the "remove moment.js" benefit.
If you're building internal enterprise tools (Chrome-only), Temporal is viable natively today. No polyfill, no waiting.
If you're in fintech or scheduling (need nanosecond precision or robust timezone handling), evaluate whether your user base can tolerate 50% polyfilled. If yes, ship Temporal. If no, wait.
Heads up: Safari will likely ship Temporal in Safari 19 (September 2026) or Safari 20 (March 2027). Once Can I Use crosses 75%, the mass migration from date-fns to Temporal begins. Until then, two ecosystems coexist: native (Chrome/Firefox early adopters) and polyfilled (real-world cross-browser production).
Brendan Eich took 10 days to create Date in 1995. Java deprecated it in 1997. JavaScript waited 27 years to fix it. And now that Temporal's here, Safari makes you wait 1-2 more years. That's the web platform in 2026.
