Starting with Chrome 144, support for the Temporal API has been added, bringing a modern date and time API to the web and marking the first stable Chrome release to ship the long-running TC39 proposal. The change was highlighted in Chrome’s release blog, which positions Temporal as a modern alternative to JavaScript’s long criticised Date object.
Temporal, exposed as a global Temporal namespace, aims to fix well known issues such as unclear parsing rules, awkward time zone handling, and mutable date arithmetic, by providing distinct types for distinct jobs and returning new values rather than mutating existing ones. MDN describes it as a full replacement for Date, with built in time zones and calendars, wall clock conversions, arithmetic, and formatting.
One of the biggest practical wins is that developers can represent a date without accidentally smuggling in a time zone and time of day. For example:
const start = Temporal.PlainDate.from('2026-02-13');
const end = start.add({ days: 7 });
When time zones matter, the API makes them explicit. Instead of formatting a Date into a string and hoping no implicit conversion happened on the way, ZonedDateTime keeps the zone in the value:
const now = Temporal.Now.zonedDateTimeISO('Europe/London');
const later = now.add({ hours: 2 });
Online commentary has focused on a mixture of relief and adoption anxiety. In a popular Reddit thread, developers welcomed the prospect of ditching third party libraries for fundamental date handling. One commenter said it had taken a long time and called out the pitfalls of Date, noting that having to ship libraries for something as fundamental as date handling was always annoying
.
Depsite its rollout in Chrome, there may be some delay in its usage, due to lack of support in all browsers and framework and library adoption, as noted from a comment on the reddit thread:
Curious how quickly libraries and frameworks will start adopting it now that it’s shipping in Chrome, especially for apps that rely heavily on scheduling or analytics.
A recent medium post expands on this further and argues that despite Chrome shipping Temporal, real production usage is still constrained by support gaps, especially on Safari and on mobile where feature lag tends to be more pronounced.
GitHub and standards tracking has also been part of the reaction. The Temporal proposal remains at Stage 3, but its repository is now tracking remaining work aimed at reaching Stage 4, which would fully standardise the API as part of ECMAScript.
For migration, most teams are likely to adopt Temporal incrementally. The proposal’s own documentation is a starting point to understand the type model and the intended usage patterns, while MDN currently provides the most accessible reference for day to day API details.
Temporal’s arrival also shifts the competitive landscape for date tooling. Libraries like Luxon, date-fns, Day.js, and the now largely legacy Moment.js will continue to matter where cross browser support is required, but over time they may move up the stack towards convenience wrappers and opinionated formatting, rather than patching fundamental language level gaps.
Temporal is a modern date and time API proposal developed by the TC39 committee, the standards body responsible for ECMAScript. It provides a comprehensive suite of types for handling dates, times, time zones, and calendar systems, addressing fundamental issues with JavaScript’s legacy Date object. The API offers immutable value types, explicit time zone handling, and support for multiple calendar systems, making it suitable for internationalized applications.
