Chrome 144 Release Preview: The Temporal API Finally Fixes JavaScript’s 30-Year Date Problem

The Chrome 144 release preview centers on a feature JavaScript developers have been waiting decades for: the Temporal API. Scheduled to land on January 7, 2026, Chrome 144 brings the most significant update to JavaScript’s date and time handling since the language’s creation in 1995. For the millions of developers who’ve wrestled with Date’s quirks—or reached for Moment.js and date-fns to avoid them entirely—this is the release that fundamentally changes how we build scheduling systems, internationalized applications, and anything that touches a calendar.

This isn’t just another browser update with incremental improvements. Chrome 144 ships the Temporal API to stable, ending JavaScript’s 30-year dependency on a broken Date object copied from Java’s failed 1995 implementation. It also brings View Transitions waitUntil() for advanced animation control, WebGPU enhancements, and—in a significant policy shift—begins deprecating major Privacy Sandbox APIs as Google reverses course on third-party cookie removal.

The Temporal API: JavaScript’s Date Object Finally Gets Replaced

The headline feature is Temporal, a complete replacement for JavaScript’s Date object. When JavaScript was created in 1995, its Date implementation was hastily copied from Java’s java.util.Date. Java fixed its date API in 1997. JavaScript has been stuck with the same broken interface for 30 years.

What Was Wrong with Date?

JavaScript’s Date object has fundamental design flaws that have plagued developers for three decades:

• No time zone support: Date only understands the user’s local time and UTC. You can’t represent “2:00 PM in Tokyo” without manual offset calculations.
• Mutable objects: Date instances can be modified in place, leading to hard-to-trace bugs when passing dates between functions.
• Unreliable parsing: Date.parse() behavior varies across browsers and locales, making date string parsing a minefield.
• Daylight Saving Time nightmares: Calculations across DST transitions are error-prone and require defensive coding.
• No calendar support: Date assumes Gregorian calendars. Building apps for Hebrew, Islamic, or Chinese calendars requires external libraries.

These issues forced most production codebases to rely on third-party libraries like Moment.js (now deprecated), date-fns, or Luxon. Temporal eliminates that dependency.

What Temporal Brings

Temporal provides over 200 utility methods organized around clear concepts:

• Temporal.Instant: A fixed point in time (like a Unix timestamp), independent of time zones
• Temporal.ZonedDateTime: A date-time with a specific time zone (e.g., “2026-01-07T14:00:00[America/New_York]”)
• Temporal.PlainDateTime: A date-time without time zone context (useful for “wall clock” times)
• Temporal.Duration: The difference between two points in time, with human-readable units
• Temporal.PlainDate, PlainTime, PlainYearMonth, PlainMonthDay: Specialized types for partial date/time representations

All Temporal objects are immutable. Operations return new instances rather than modifying existing ones, eliminating entire classes of bugs.

Real-World Examples

Here’s what working with time zones looks like in Temporal:

// Get current time in specific time zones
const now = Temporal.Now.zonedDateTimeISO();
const tokyo = now.withTimeZone('Asia/Tokyo');
const newYork = now.withTimeZone('America/New_York');

console.log(`Tokyo: ${tokyo.toString()}`);
console.log(`New York: ${newYork.toString()}`);
// Tokyo: 2026-01-07T23:00:00+09:00[Asia/Tokyo]
// New York: 2026-01-07T09:00:00-05:00[America/New_York]

Duration calculations are finally readable:

const launch = Temporal.Instant.from('2026-06-15T12:00:00Z');
const now = Temporal.Now.instant();
const timeUntil = now.until(launch, { largestUnit: 'day' });

console.log(timeUntil.toString()); // "P159DT3H" (159 days, 3 hours)
console.log(timeUntil.toLocaleString('en-US')); // "159 days, 3 hours"

And working with non-Gregorian calendars is built-in:

// Find the next Chinese New Year
const chineseNewYear = Temporal.PlainMonthDay.from({
  monthCode: 'M01',
  day: 1,
  calendar: 'chinese'
});
const currentYear = Temporal.Now.plainDateISO().withCalendar('chinese').year;
let nextCNY = chineseNewYear.toPlainDate({ year: currentYear });
if (Temporal.PlainDate.compare(nextCNY, Temporal.Now.plainDateISO()) <= 0) {
  nextCNY = nextCNY.add({ years: 1 });
}
console.log(`Next Chinese New Year: ${nextCNY.withCalendar('iso8601').toLocaleString()}`);
// Next Chinese New Year: 1/29/2026

View Transitions Get Advanced Control

Chrome 144 adds the waitUntil() method to View Transitions, solving a critical limitation. Previously, View Transitions destroyed their pseudo-element tree automatically when animations finished. This was fine for simple transitions but broke advanced use cases—especially scroll-driven animations, where scrolling backward should re-animate pseudo-elements rather than destroy them.

waitUntil() accepts a promise and keeps the pseudo-tree alive until that promise settles:

const transition = document.startViewTransition(() => {
  // Update DOM
});

// Keep transition alive until scroll completes
transition.waitUntil(new Promise(resolve => {
  scrollContainer.addEventListener('scrollend', resolve, { once: true });
}));

This unlocks complex patterns like tying view transitions to scroll position, gesture completion, or async data loading.

WebGPU and Graphics Updates

Chrome 144 brings two WebGPU improvements for compute and graphics developers:

• subgroup_id feature: Exposes subgroup_id and num_subgroups built-ins in WGSL shaders, enabling more efficient GPU workgroup management
• Uniform buffer standard layout: Removes the 16-byte alignment requirement for array elements in uniform buffers, simplifying shader code and reducing memory overhead

For developers building WebGPU applications, the uniform buffer change means you no longer need to pad structs to 16-byte boundaries—a significant quality-of-life improvement.

CSS and UI Polish

Chrome 144 includes several CSS enhancements focused on scroll interactions and positioning:

• CSS anchor positioning with transforms: Anchor-positioned elements now correctly resolve anchor() and anchor-size() functions against transformed anchors
• @scroll-state scrolled support: Style descendants of containers based on scroll direction (@container scroll-state(scrolled: top))
• Find-in-page highlight styling: The ::search-text pseudo-element lets you customize browser find-in-page highlight colors
• overscroll-behavior fixes: Now respects the property for keyboard scrolls and non-scrollable containers

Privacy Sandbox Deprecations: The Third-Party Cookie Pivot

In a major policy reversal, Chrome 144 begins deprecating the Privacy Sandbox APIs Google built to replace third-party cookies. After announcing in July 2024 that Chrome would not remove third-party cookies, Chrome is now phasing out:

• Topics API (interest-based advertising)
• Protected Audience API (formerly FLEDGE, for remarketing)
• Shared Storage API
• Attribution Reporting API
• Private Aggregation API
• Related Website Sets
• document.requestStorageAccessFor

These APIs are being deprecated—not removed yet—but the message is clear: Google is walking back its cookieless future. If you built ad-tech tooling around Privacy Sandbox, you'll need to reassess your strategy.

Why the Temporal API Is a Turning Point

Temporal isn't just a nice-to-have. It's a corrective to one of JavaScript's most notorious design flaws. Date's problems have generated countless Stack Overflow questions, bug reports, and hours of wasted developer time. The fact that nearly every production JavaScript codebase pulls in a date library (Moment.js had 18 million weekly npm downloads before deprecation) shows how broken the status quo was.

Temporal shipping in Chrome 144 means:

• Bundle size reductions: Apps can drop Moment.js, date-fns, or Luxon for new code, potentially saving 50-200 KB of compressed JavaScript
• Better internationalization: Built-in calendar and time zone support makes building global apps easier
• Fewer bugs: Immutable objects and clear APIs reduce the surface area for date-related bugs
• Standards-based: Temporal is a Stage 3 TC39 proposal with implementations in Firefox Nightly and WebKit in progress

Chrome's implementation is built on temporal_rs, a Rust library, and leverages the ICU4X project for calendar and time zone data. This is part of Chrome's broader strategy of using memory-safe languages for critical infrastructure.

The Privacy Sandbox Reversal Matters for the Web's Future

Chrome's Privacy Sandbox deprecations signal a pragmatic retreat. Google spent years building these APIs, got pushback from advertisers and publishers, and ultimately decided that preserving third-party cookies (with enhanced user controls) was more viable than forcing the industry to adopt new primitives.

For web developers, this means:

• Third-party cookies aren't going away in Chrome (though Safari and Firefox still block them)
• You don't need to rewrite ad-tech or analytics code for Privacy Sandbox APIs
• Cross-site tracking debates shift to user choice and transparency rather than technical restrictions

Whether this is good or bad for user privacy is debatable. What's clear is that the web's privacy architecture won't change as radically as Google initially planned.

How to Prepare for Chrome 144

1. Start Learning Temporal Today

Temporal is available now in Chrome Beta (144) and can be tested using the @js-temporal/polyfill in any browser. The polyfill adds ~25 KB gzipped, which is smaller than most date libraries.

Install the polyfill:

npm install @js-temporal/polyfill

Use it in your code:

import { Temporal } from '@js-temporal/polyfill';

const now = Temporal.Now.instant();
console.log(now.toString());

Check out the comprehensive TC39 Temporal documentation and the 270+ pages of MDN docs added this year.

2. Audit Your Date Usage

Run a codebase audit for Date usage:

grep -r "new Date" src/
grep -r "Date.now()" src/

Identify high-risk areas:

• Time zone conversions
• Date arithmetic (adding days, months, years)
• Scheduling or calendar logic
• Internationalized date formatting

For new features, default to Temporal. For existing code, plan incremental migration—Temporal and Date can coexist.

3. Test in Chrome Beta

Chrome 144 Beta is live now (December 3-18, 2025). Download Chrome Beta and test your applications against the final implementation. Report any issues to Chromium's issue tracker.

4. Check Privacy Sandbox Dependencies

If you implemented Topics, Protected Audience, or Attribution Reporting APIs, review your code. These APIs won't break immediately (they're deprecated, not removed), but you should plan to remove dependencies. Chrome's reversal to third-party cookies means you can revert to traditional tracking mechanisms (if that aligns with your privacy policies).

5. Explore View Transitions waitUntil()

If you're using View Transitions with scroll-driven animations or complex async workflows, waitUntil() solves a major pain point. Test in Chrome Beta to see if it unblocks patterns you've been avoiding.

6. Monitor Browser Support

Temporal is shipping in:

• Chrome 144: January 7, 2026 (confirmed)
• Firefox Nightly: Available behind a flag (javascript.options.experimental.temporal)
• Safari: In development (partial implementation in WebKit)

Full cross-browser support is likely 6-12 months away. Use feature detection:

if (typeof Temporal !== 'undefined') {
  // Use Temporal
} else {
  // Fall back to date-fns or polyfill
}

When to Adopt Temporal

You should start using Temporal for:

• New projects: Default to Temporal for all date/time logic
• Time-zone-heavy apps: Scheduling tools, calendar apps, booking systems
• Internationalized apps: Apps supporting multiple calendars (Hebrew, Islamic, etc.)
• Progressive web apps: Where polyfills are acceptable for older browsers

Wait on Temporal if:

• You need to support IE11 or very old browsers (Date will remain supported indefinitely)
• Your app has minimal date logic and Date "just works"
• You can't afford the polyfill size and need to wait for native support