Apr 29, 2026 23:00:00

The 9-year journey to the birth of the Temporal object, which revolutionized the concept of dates in JavaScript.

A new date and time API called '

Temporal ' is being introduced, which replaces the Date object that is originally built into ECMAScript, the standard for JavaScript. Temporal aims to solve many of the challenges in date and time manipulation in JavaScript.

Temporal: The 9-Year Journey to Fix Time in JavaScript | Bloomberg JS Blog
https://bloomberg.github.io/js-blog/post/temporal/

JavaScript's Date object was implemented in just 10 days in 1995 by Brendan Eich , based on Java's Date implementation. At the time, it wasn't anticipated that JavaScript would perform complex processing, so the implementation wasn't considered problematic.

However, in the 2010s, JavaScript reached a point where it was supporting complex processing across all time zones, and

various design constraints and problems, such as those listed below, plagued developers.

Mutability : The risk of unintended value changes resulting from an object being modifiable.
- Parsing ambiguity : Unintended interpretations may occur when parsing date strings.
- Inconsistency with time zones and calendars : It is weak in handling time zones and calendars other than the Gregorian calendar, which can lead to unexpected results when internationalizing the system.

Mutability refers to the fact that methods of a Date object can modify the object itself, which can lead to unintended side effects when the same object is referenced in multiple places. In particular, because JavaScript functions use

pass-by-reference for argument, changing a Date object within a function will affect other code that references that object. In other words, using a function without knowing its inner workings could potentially change the Date object passed as an argument, compromising the safety of the code.
[code]
const date = new Date('2026-02-25T00:00:00Z');
console.log(date.toISOString());
// Outputs '2026-02-25T00:00:00.000Z'

function addOneDay(d) {
d.setDate(d.getDate() + 1); // This modifies the Date object passed as an argument.
return d;
}

addOneDay(date); // From an external perspective, this function simply adds to the date and returns it, but in reality, it also modifies the Date object passed as an argument.

console.log(date.toISOString());
// Outputs '2026-02-26T00:00:00.000Z'
[code]

The ambiguity of parsing is a problem where the constructor of the Date object and the Date.parse() method interpret date strings differently depending on the browser and implementation. For example, the string '2026-02-25 15:15:00' is similar to the ISO 8601 format but has slight differences, and the parsing result is not defined in the specification . Therefore, the same code can produce different results in different environments, leading to unexpected bugs.
[code]
new Date('2026-06-25 15:15:00').toISOString();
// This constructor may be interpreted differently by different browsers.
// Interpreted as the date in the local time zone
// Interpreted as UTC date
// - Error (RangeError: invalid date) may occur.
[code]

A well-known example of inconsistency with time zone calendars is the following code:
[code]
const billingDate = new Date('Sat Jan 31 2026');
billingDate.setMonth(billingDate.getMonth() + 1);
// Expected date: February 28th
// Actual value: March 2nd
[code]

Traditionally, attempting to resolve issues related to Date would involve relying on third-party libraries like Moment.js , which introduced new challenges such as increased bundle size and the management of locale and timezone data.

Proposed at the 2017

TC39 General Assembly with the aim of fundamentally resolving the issues surrounding the Date object, Temporal aims to introduce a modern date and time API into the JavaScript standard.

Alternatives for the Date object
- Provides multiple DateTime types
- Immutable design
First-class support for time zones and calendars

The proposal will be scrutinized through a series of processes.

Stage 0 : Idea presentation
Stage 1 : The problem domain has been accepted.
Stage 2 : The design plan has been finalized, but work is still ongoing.
Stage 2.7 : The proposal has been approved in principle and is awaiting testing and feedback.
Stage 3 : Implementation and Feedback
Stage 4 : Standardization

After Microsoft's Maggie Johnson-Pint brought the Temporal proposal to TC39 and it advanced to Stage 1, she, along with fellow Microsoft members Matt Johnson-Pint and Brian Terlson , took the lead. Around the same time, Bloomberg's Andrew Paprocki and Igalia's Daniel Ehrenberg were discussing how to make time zones configurable in V8 when they noticed similarities to the Temporal proposal, which led to Bloomberg and Igalia joining the implementation of Temporal. Bloomberg's Philipp Dunkel persuaded his company to invest in Temporal, and Igalia's Philip Chimento and Ujjwal Sharma became full-time members of the team working on Temporal's development.

Furthermore, Richard Gibson contributed as a Stage 3 reviewer, cleaning up and contributing to the specifications. Shane Carr from Google's internationalization team participated, handling internationalization topics such as calendars. Justin Grant volunteered in 2020, drawing on his past work experience to make a significant contribution to the release of the Temporal.ZonedDateTime API, which resolves issues related to Daylight Saving Time (DST).

Implementing Temporal was extremely difficult due to its massive scale and the most extensive changes it had ever brought to JavaScript. The specification was enormous, making it very difficult for an individual to implement, and the frequent changes to the specification made it even harder to keep up with the implementation. The sheer number of tests added to the official ECMAScript test suite (Test262) illustrates just how challenging Temporal's implementation was. As of the time of writing, Temporal has approximately 4500 test items, a significantly larger number than other built-in features, including Date.