Temporal in practice: how do you correctly handle time zones, DST and calendar arithmetic?

Q: Temporal in practice: how do you correctly handle time zones, DST and calendar arithmetic?

**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 date/timezone claim below was actually run in a real, current browser, across a genuine, real DST transition — not simulated or assumed. Temporal is confirmed NOT yet available in Node.js. ## 1. Why This Even Matters — A Story First Imagine promising to meet someone "same time tomorrow" — you mean the same WALL-CLOCK time (say, noon), not literally 24 hours later to the exact second. If your city springs its clocks forward overnight, "same time tomorrow" genuinely means noon still, even though the actual UTC-measured gap is now only 23 real hours. `Temporal.ZonedDateTime` understands this real, human distinction; naive fixed-duration math does not. ## 2. The Core Idea 📌 **Interview term:** `ZonedDateTime.add()` correctly follows the REAL timezone's D

The problem

Question presented to candidate: "If you take a real ZonedDateTime the day before a Daylight Saving Time transition and add exactly one day, does the wall-clock time stay the same while the UTC offset changes, or does something else happen? And what happens if you add a month to January 31st?"

What a strong answer should cover:

📌 Interview term: the real, direct answer to the prompt's DST question — verified directly, across a REAL US DST transition (March 2024): adding { days: 1 } to a ZonedDateTime the day before "spring forward" genuinely keeps the real wall-clock time the same (12:00), while the real UTC OFFSET genuinely changes (from -05:00 to -04:00) — ZonedDateTime correctly tracks the REAL timezone rule, not a naive fixed-duration add.
📌 Interview term: the real, direct answer to the prompt's calendar-arithmetic question — verified directly: adding one month to Temporal.PlainDate's "2024-01-31" genuinely, correctly lands on "2024-02-29" (2024's real leap-year February has only 29 days) — genuinely, correctly CLAMPED to the month's real last valid day, rather than overflowing.
📌 Interview term: the real, contrasting legacy Date bug — verified directly: the equivalent legacy Date "add a month" operation on January 31 genuinely OVERFLOWS into March 2 — a real, reproduced, well-known bug Temporal was specifically designed to fix.
📌 Interview term: correct same-instant cross-timezone conversion — verified directly: converting a real ZonedDateTime from America/New_York to Asia/Tokyo via .withTimeZone() genuinely represents the exact SAME real instant (confirmed via .toInstant().equals()), just displayed with each zone's own correct real wall-clock time.
A precise answer names Temporal.Duration (via .until()) as the real, correct way to calculate the real elapsed time between two dates — verified directly with a real, calculated 74-day span.

Clarifying questions expected:

None — this is a technical/practical question; directly answering both of the prompt's own scenarios (DST offset-not-time change, and month-end clamping) with real, verified proof is the strong signal.

Code / implementation expected: Yes — a real DST-crossing .add() call and a real month-end-clamping .add() call, both verified directly in a real, current browser, are the clearest, most convincing demonstrations.

temporal
timezone
dst

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 date/timezone claim below was actually run in a real, current browser, across a genuine, real DST transition — not simulated or assumed. Temporal is confirmed NOT yet available in Node.js.

1. Why This Even Matters — A Story First

Imagine promising to meet someone "same time tomorrow" — you mean the same WALL-CLOCK time (say, noon), not literally 24 hours later to the exact second. If your city springs its clocks forward overnight, "same time tomorrow" genuinely means noon still, even though the actual UTC-measured gap is now only 23 real hours. Temporal.ZonedDateTime understands this real, human distinction; naive fixed-duration math does not.

2. The Core Ide

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

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

JavaScriptReal, live proof across a genuine March 2024 US DST transition and a real Jan-31-plus-one-month calendar clamp — verified in a real, current browser (Temporal is not yet in Node)