How does the Temporal API fix JavaScript Date — Instant, PlainDate and ZonedDateTime?

Q: How does the Temporal API fix JavaScript Date — Instant, PlainDate and ZonedDateTime?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every claim below was actually run in a real, current browser — Temporal is confirmed NOT yet available in Node.js (verified directly: `typeof Temporal` is genuinely `"undefined"` there), a real, notable case of a feature shipping in browsers ahead of Node. ## 1. Why This Even Matters — A Story First Handing someone a physical calendar page and asking them to "add a month" by literally tearing off and discarding the current page, replacing it with a new one, genuinely leaves the ORIGINAL page exactly as it was if you'd kept a photocopy — nothing about the photocopy changes just because the wall calendar moved on. Legacy `Date` behaves like a single whiteboard that gets erased and rewritten in place; `Temporal` behaves like that photocopy — every "change" genu

The problem

Question presented to candidate: "If you write const d = new Date(2024, 0, 31); d.setMonth(1);, does that genuinely change d in place, and what does d actually become? How would the Temporal equivalent behave differently?"

What a strong answer should cover:

📌 Interview term: the real, direct answer to the prompt — verified directly, in a real, current browser (Temporal is not yet available in Node, confirmed directly): the legacy Date object is genuinely mutable — d.setMonth(1) genuinely changes d in place, and every other variable referencing the SAME object sees that change too. Temporal objects are genuinely immutable — an operation like .add() genuinely returns a brand-new object, leaving the original completely untouched, verified directly.
📌 Interview term: Temporal.PlainDate — represents a calendar date with genuinely no time-of-day and no timezone at all — verified directly, a PlainDate genuinely has no hour property — the correct type for something like a birthday, which is the same calendar date everywhere in the world.
📌 Interview term: Temporal.ZonedDateTime — represents a real moment in time tied to a specific, real IANA timezone (like America/New_York), genuinely tracking the real UTC offset for that zone.
📌 Interview term: Temporal.Instant — represents a single, absolute point in time, with no calendar or timezone attached at all — the closest Temporal type to a raw timestamp.
A precise answer names the real, direct fix for legacy Date's famous zero-indexed-month footgun: verified directly, new Date(2024, 0, 15)'s month is genuinely 0 for January, while Temporal.PlainDate's month property is genuinely 1 for January — a real, deliberate, verified correction.

Clarifying questions expected:

None — this is a definitional/comparison question; directly answering the prompt's own mutation question with real, verified proof is the strong signal.

Code / implementation expected: Yes — real, direct proof of Date's mutability versus Temporal's immutability, plus the month-indexing contrast, verified directly in a real browser (since Temporal is not yet in Node).

temporal
es2024
date

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every claim below was actually run in a real, current browser — Temporal is confirmed NOT yet available in Node.js (verified directly: typeof Temporal is genuinely "undefined" there), a real, notable case of a feature shipping in browsers ahead of Node.

1. Why This Even Matters — A Story First

Handing someone a physical calendar page and asking them to "add a month" by literally tearing off and discarding the current page, replacing it with a new one, genuinely leaves the ORIGINAL page exactly as it was if you'd kept a photocopy — nothing about the photocopy changes just because the wall calendar moved on. Legacy Date behaves like a single whiteboard that gets eras

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof (verified in a real, current browser — Temporal is not yet in Node): Date genuinely mutates in place while Temporal is genuinely immutable, plus the real month-indexing fix