Prompt and context
A global booking system receives “New York time 2026-11-01 01:30” and displays and notifies participants in their own zones. Using JavaScript Temporal, design parsing, zone binding, persistence, and display while handling nonexistent or repeated local times during daylight-saving transitions. Do not collapse date, time, and zone semantics into one string or Date object.
What the interviewer is testing
The signals are distinguishing Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime, and Temporal.PlainDate, understanding IANA rules, DST ambiguity, precision, and serialization. Strong answers explain why a business calendar date is not automatically a UTC instant and how to preserve the calendar system.
Clarifying questions to ask first
Input semantics
Confirm whether the input is a wall-clock time in a named zone or an already resolved instant, and whether the zone comes from the event, organization, or browser. Without a zone, local time is ambiguous.
DST ambiguity policy
Ask whether nonexistent or repeated times should be rejected, choose earlier or later, or require confirmation. The policy belongs in the product contract, not in an accidental runtime default.
Persistence requirement
Determine whether a reminder is one absolute instant or repeats every year in a local calendar. A one-off booking and a birthday-like rule require different Temporal types.
A 30-second answer framework
“Keep user input as PlainDateTime plus an explicit IANA zone, then apply the product’s policy to create ZonedDateTime and Instant. Persist an Instant for a one-off reminder and convert it to each viewer’s zone for display. Persist local date, time, zone, and calendar rules for recurring events. Explicitly reject or choose a DST disambiguation and preserve the original semantics; avoid Date’s implicit local-zone parsing.”
Deep-dive answer steps
Step 1: Choose the correct type
PlainDate is a calendar date without a zone, PlainDateTime is a wall-clock date and time without a zone, ZonedDateTime binds an IANA zone, and Instant is one point on the timeline. Select the type from business meaning first.
Step 2: Parse and bind the zone
Parse the user input into PlainDateTime, obtain a trusted zone identifier, and combine them into ZonedDateTime. Never silently use the browser or server default zone as the event zone.
Step 3: Handle DST transitions
Spring-forward creates nonexistent local times; fall-back creates repeated local times. Apply an explicit disambiguation such as rejecting and asking the user again, or choosing earlier/later when the requirement allows it. Record that choice with the booking.
Step 4: Convert to the reminder instant
For a one-off booking, obtain an Instant from ZonedDateTime and persist a normalized string. Schedule by the Instant; convert it to the viewer’s zone only at display time instead of reinterpreting the original wall-clock text.
Step 5: Preserve recurring-event semantics
An annual event at 09:00 local cannot be stored as one UTC offset because DST changes that offset. Persist PlainDate, PlainTime, the IANA zone, and calendar system, then resolve a new ZonedDateTime for each occurrence.
Step 6: Define precision and calendar
Specify whether milliseconds, microseconds, or nanoseconds are required; do not truncate during serialization and break ordering. For non-ISO business calendars, persist the calendar identifier instead of treating its date as an ISO date.
Step 7: Test boundaries
Cover spring-forward and fall-back, year boundaries, leap days, time-zone database updates, locale differences, and serialization round trips. Assert the instant, local display, and recurrence rule separately rather than comparing strings alone.
High-quality sample answer
I would parse input as PlainDateTime, require an IANA zone, and apply an explicit DST policy to create ZonedDateTime. Persist Instant for one-off reminders and convert it for each viewer; persist local date, time, zone, and calendar rules for recurrences and resolve a new instant each time. Tests cover nonexistent and repeated times, leap days, zone-database updates, and precision. This avoids Date’s implicit-zone behavior.
Common mistakes
- Mistake: Treating
PlainDateTimeas UTC. → Why: It has no zone semantics. → Improve: Bind an explicit IANA zone first. - Mistake: Persisting only a UTC offset for annual events. → Why: DST changes the local offset. → Improve: Persist local time and zone rules.
- Mistake: Ignoring the repeated fall-back time. → Why: One wall time maps to two instants. → Improve: Reject or explicitly choose earlier/later.
- Mistake: Validating only string equality. → Why: Strings do not prove instant or calendar semantics. → Improve: Assert Instant, ZonedDateTime, and recurrence behavior separately.
Follow-up questions and answers
Follow-up 1: When should you persist an Instant?
When the event means one absolute occurrence on the timeline, such as sending a reminder or recording a payment. The viewer’s zone changes presentation, not the instant.
Follow-up 2: Why should a birthday not be stored as an Instant?
A birthday is a local calendar date, not usually one globally simultaneous instant. Store date, zone, and calendar rules, then compute an instant for each occurrence.
Follow-up 3: Can a time-zone database update affect saved bookings?
Yes. Future local-time rules can change. Preserve the original zone and semantics, record a rule version when needed, and define how recalculation is handled.
Follow-up 4: Does Temporal automatically decide DST ambiguity?
The API offers disambiguation options, but the product must choose reject, earlier, later, or compatible behavior. A default option is not a business policy.