TC39’s March 2026 meeting marked a major milestone for the JavaScript ecosystem: the long-awaited Temporal API has officially reached Stage 4, securing its place in the upcoming ECMAScript 2026 specification.
Temporal is a modern replacement for JavaScript’s decades-old Date object, which has long been criticized for its confusing behavior, lack of built-in time zone support, and mutable design. The new API introduces immutable date and time types, built-in time zone and calendar support, and clearer primitives for performing date and time arithmetic.
In a recent Bloomberg writeup about the proposal’s development, TC39 co-chair and Bloomberg engineering manager Rob Palmer explained that the limitations of the existing Date API have historically forced developers to rely on large third-party libraries. “While there are many libraries to solve these problems, such as Moment.js, they all require downloading a lot of data – especially for time zones to be transferred,” Palmer said. “Your browser is downloading tens, maybe hundreds, of kilobytes that should be built into the browser.”
According to Bloomberg engineer and Temporal champion Jason Williams, the feature represents an unusually large addition to the language itself. Writing on Bloomberg’s JavaScript blog, Williams described Temporal as “the biggest addition to ECMAScript since ES2015.”
The committee also advanced several other proposals across the ECMAScript pipeline, including updates to internationalization features, new module capabilities, and improvements to error handling.
Inside the Temporal API#
Temporal’s advancement to Stage 4 concludes nearly a decade of work on a new date and time API for JavaScript. The proposal was first introduced in 2017 and has since been developed by contributors from multiple organizations, including Bloomberg, Igalia, Google, Microsoft, and independent experts.
Rather than extending the existing Date object, the proposal introduces a new global Temporal namespace containing several specialized types for working with dates and times. These include Temporal.Instant for representing an exact moment in time, Temporal.ZonedDateTime for values tied to a specific time zone, and “plain” types such as Temporal.PlainDate and Temporal.PlainTime for calendar values without time zone context.
The API is designed around immutable values, avoiding the common pitfalls of the mutable Date object. Temporal objects also provide first-class support for time zones, calendars, and daylight saving transitions, allowing date and time arithmetic to behave predictably across regions and calendar systems.
Implementations of Temporal are already appearing across JavaScript engines and tools. Support has landed in Firefox and Chromium-based browsers such as Chrome and Edge, with partial support available in Safari’s Technology Preview. TypeScript 6.0 also includes type definitions for the API, and Node.js support is expected in a future release.
With Stage 4 approval, Temporal will become part of the ECMAScript 2026 specification.
Other Proposals TC39 Advanced at the March 2026 Meeting#
Several additional proposals advanced through the TC39 process during the meeting.
The Intl era and monthCode proposal reached Stage 4 alongside Temporal. The feature adds standardized access to era and month code information within the JavaScript internationalization APIs, helping improve support for non-Gregorian calendar systems.
The Import text proposal advanced to Stage 3. It introduces a way to import text files directly as modules, simplifying workflows that currently require build-time tooling or custom loaders.
Two proposals advanced to Stage 2.7, a stage sometimes used informally within TC39 to indicate that a proposal is close to Stage 3 but still undergoing final validation and testing.
The Error stack accessor proposal aims to standardize the Error.prototype.stack accessor, which is widely implemented in JavaScript engines but has historically lacked specification-level consistency.
The Iterator includes proposal introduces a convenience method for iterators that mirrors the behavior of Array.prototype.includes.
Two additional proposals reached Stage 2: Intl unit protocol, which explores improvements to how measurement units are represented in internationalization APIs, and Thenable curtailment, which addresses edge cases around thenable objects in JavaScript’s promise resolution process.
Finally, the Error code property proposal advanced to Stage 1, beginning early exploration into adding standardized error codes to JavaScript error objects.
TC39 also withdrew the Dynamic import host adjustment proposal during the meeting.
The committee meets regularly to review proposals and advance the ECMAScript standard through its staged proposal process. Detailed meeting notes from the March 2026 plenary are expected to be published in the TC39 notes repository in the coming weeks.