Chrome 144 ships Temporal. Here’s how to use it without breaking prod.

I’ve watched teams lose a full day to a one-hour DST jump. Temporal finally gives JavaScript a date API that fights back.

Chrome 144 puts the Temporal API in front of real users. If your app books meetings, bills by day, or stores “local midnight” anywhere, you should treat this as a migration, not a fun new toy.

Temporal replaces Date for one reason: Date lies

This bit me when we scheduled “9:00 AM local time” reminders across time zones. Date happily turned it into “some timestamp” and we shipped reminders at 8:00 AM for a chunk of users after a DST change.

Date makes it easy to do the wrong thing. It mixes time zones, parsing, and mutation into one object, then smiles while your bug report queue fills up.

• Date can’t represent a time zone: you get local time or UTC, then you hand-roll offsets and pray you did not cross a DST boundary.
• Date mutates: one helper “fixes” a Date in-place, another function reuses it, and you debug a ghost.
• Date parsing stays slippery: Date.parse accepts strings that behave differently across environments, so the same input can turn into different instants.

The Temporal mental model I actually use

Pick the right type first. It sounds basic, but it prevents 80% of the mistakes.

I split the world into two buckets: “a point in time” and “a calendar thing humans talk about.” Temporal gives you types for both, and it stops you from mixing them by accident.

• Use Temporal.Instant for storage and logs: it represents a precise moment, like an epoch timestamp, and it does not care about time zones.
• Use Temporal.ZonedDateTime for meetings: it keeps the IANA zone, so “America/New_York” stays “America/New_York” through DST.
• Use Temporal.PlainDate and PlainTime for “wall clock” rules: “every day at 09:00” should not start life as a timestamp.
• Use Temporal.Duration for readable diffs: you can ask for “largestUnit: ‘day’” instead of dividing milliseconds like it’s 2009.

Code you can steal: time zones, durations, and “wall clock” times

Time zones become boring. That’s the point.

With Temporal, you can take “now” and view it in another zone without inventing offset math. You still need to decide what you mean, but the API stops tripping you.

• Show the same instant in Tokyo and New York: take a ZonedDateTime and switch zones.
• Compute a human-friendly countdown: use until with largestUnit, then format.

Example patterns, trimmed down:

Time zones: Get “now,” then switch time zones using withTimeZone().

Countdown: Parse a fixed launch instant, then call now.until(launch, { largestUnit: ‘day’ }).

Local schedules: Start with PlainDateTime or PlainTime for rules like “09:00,” then combine with a zone at the edge.

If you store “user local time” as an epoch timestamp in your database, you already lost. Store the wall-clock parts and the zone, then derive instants when you need them.

How I’d roll this out (without a flag day)

Do not rewrite everything. Seriously.

Temporal and Date can coexist. In most teams, the safest path is to migrate the high-risk surfaces first, then tighten rules so new code does not add more Date debt.

• Step 1: audit Date usage: search for new Date(, Date.parse, and any hand-rolled offset math. Tag the files that touch scheduling, billing cutoffs, and “local midnight.”
• Step 2: add a guardrail: block new Date usage in new code paths with lint rules or code review checks, so you stop the bleeding.
• Step 3: migrate boundaries first: change storage and API edges to Instant (or ISO strings) before you refactor UI helpers.
• Step 4: test three time zones: UTC, a DST-observing zone (America/New_York), and a non-DST zone (Asia/Tokyo). I do not trust “known issues: none” from any project.

Some folks skip canaries for patch-level browser features. I don’t, but I get it. If your app schedules real money or real humans, test this twice.

Temporal polyfill and browser support: ship it like you mean it

Feature detection first. Always.

Use native Temporal when it exists, otherwise load a polyfill or fall back to your existing library. The exact bundle cost depends on how you ship it, so measure it in your build instead of copying someone else’s number.

• Native check: gate on typeof Temporal !== ‘undefined’.
• Polyfill strategy: consider loading it only for browsers that need it, especially if your app already runs tight on bundle budgets.

Two other Chrome 144 changes that might hit your team

Temporal will get the headlines. The rest still matters.

Chrome 144 also tweaks platform APIs that show up in UI polish work and graphics-heavy apps, plus it starts backing away from parts of Privacy Sandbox. If you own those areas, you should at least skim the release notes.

• View Transitions waitUntil(): it keeps the transition pseudo-element tree alive until your promise settles. This helps when scroll or async work drives the animation.
• WebGPU uniform buffer layout: it relaxes 16-byte padding constraints for some uniform buffer layouts, which reduces shader boilerplate if you fought that alignment rule before.

Privacy Sandbox deprecations: do not sleep on this if you ship ad-tech

This is the weirdest part of the release. It’s not a code tweak, it’s a direction change.

Chrome 144 starts deprecating several Privacy Sandbox APIs, including Topics and Protected Audience. If you built tooling around them, plan the exit now, even if nothing breaks this week.

• Inventory your usage: search your codebase for Topics, Protected Audience (FLEDGE), Attribution Reporting, and related APIs.
• Talk to legal and product: cookie strategy lives outside engineering, and it will drag you into meetings whether you like it or not.

Other stuff in this release: dependency bumps, some image updates, the usual.

What I’d do today

Start small. Ship safely.

Pick one painful date workflow, migrate it to Temporal behind feature detection, and add tests that run through a DST boundary. There’s probably a better way to test this, but…

Keep Reading

• Chrome Release History
• Chrome third-party cookies: what breaks, what to ship, how to test
• Chrome Geolocation Changes (2025–2026): Keep Location Working in Production
• Chrome 144 breaks two habits: JS geolocation prompts and Topics

Frequently Asked Questions

• What is the Temporal API in JavaScript? Temporal is a new built-in JavaScript API for working with dates, times, and time zones. It ships natively in Chrome 144. Unlike the legacy Date object, Temporal objects are immutable, handle time zones correctly, and provide separate types for different concepts (PlainDate for dates without times, ZonedDateTime for full timestamps, Duration for time spans). It’s the most significant addition to JavaScript’s standard library in years.
• Can I use Temporal in production now? In Chrome 144+, yes — Temporal is available without polyfills. For cross-browser support, you’ll need a polyfill (temporal-polyfill or @js-temporal/polyfill) since Firefox and Safari haven’t shipped it yet. The safe approach: use Temporal with a polyfill, feature-detect with typeof Temporal !== ‘undefined’, and let the polyfill fall away as browsers catch up.
• How does Temporal.ZonedDateTime fix the time zone problem? Date stores everything as UTC milliseconds and converts to local time using the system’s time zone — which means the same timestamp displays differently on different machines. Temporal.ZonedDateTime explicitly stores the time zone as part of the value. When you create one with ‘America/New_York’, it stays in that zone regardless of where your code runs. No more “it works on my machine” time zone bugs.
• Should I migrate all my Date code to Temporal? Not all at once. Start with new code that handles time zones, recurring events, or duration calculations — that’s where Date is most broken. Existing Date code that works correctly with UTC timestamps doesn’t need immediate migration. The best strategy: use Temporal at your application boundaries (user input, display), keep Date where it’s working internally, and migrate gradually.