A meeting is booked for 09:00 local time in Berlin, eleven months from now. Using Temporal, why is persisting the computed UTC instant the wrong choice, and what would you store instead?

## Two different kinds of temporal fact The decision turns on what the record actually asserts. "Payment captured" is an assertion about the physical timeline. It is finished; no legislature can move it. Its natural representation is a `Temporal.Instant`, stored as an epoch value or a `Z`-suffixed ISO string. Local rendering is a presentation concern applied at read time. "Meeting at 09:00 in Berlin next March" is an assertion about a clock in a place. The instant it corresponds to is a *derived* value, computed by applying the current tzdata rules to the stated wall-clock time. Deriving it early and throwing away the inputs is the mistake. ## Why the derived instant decays Time-zone rules are political data, not physics. They change several times a year somewhere in the world: DST start and end dates move, jurisdictions abolish DST, and standard offsets change. Announcements often come weeks or months before the change takes effect — well inside the booking horizon of a calendar, a payroll run, or an annual review. When the rules change, every stored instant that was derived under the old rules silently becomes a different wall-clock time. Nothing throws. Nothing logs. The meeting simply happens an hour early, and the only evidence is angry users. Recomputing is impossible after the fact, because the original wall-clock intent was discarded at write time. The same reasoning demotes a bare UTC offset. Storing `+01:00` records what the rules said at the moment you wrote the row; storing `Europe/Berlin` records *which rules apply*, so the value re-derives correctly under whatever tzdata the host has later. The zone ID is the durable fact; the offset is a cached result. ## What to store The workable pattern is to persist the intent and derive the instant on demand: ```js // stored const row = { localDateTime: '2027-03-28T09:00', timeZone: 'Europe/Berlin' }; // derived at read time, under whatever tzdata is current const zdt = Temporal.PlainDateTime .from(row.localDateTime) .toZonedDateTime(row.timeZone, { disambiguation: 'reject' }); const fireAt = zdt.toInstant(); // hand this to the scheduler, close to the event ``` Two details are load-bearing. First, the zone must be an IANA ID; a display label like "CET" is ambiguous and not a rule set. Second, resolution can fail: if a rule change lands the stored wall-clock time inside a DST gap it does not exist, and `{ disambiguation: 'reject' }` turns that into a `RangeError` you can surface, instead of silently moving the appointment by an hour. A `ZonedDateTime` string is the compact alternative because it carries both parts: ```js const stored = zdt.toString(); // '2027-03-28T09:00:00+02:00[Europe/Berlin]' Temporal.ZonedDateTime.from(stored, { offset: 'prefer' }); ``` The `offset` option is the crux on re-parse. The default for strings is `'reject'`, which throws when the embedded offset disagrees with what the zone now says. `'prefer'` keeps the offset while it remains valid and otherwise recomputes from the zone ID, preserving the wall-clock time the user chose — which is what a booking wants. `'use'` does the opposite: it trusts the offset and preserves the exact time, letting the local clock reading drift. `'ignore'` discards the offset entirely. ## Whose zone? A meeting has participants in several places, so "the zone" needs a definition. The usual rule is that one authoritative zone owns the event — typically the organiser's, or the venue's — and every other participant's view is a rendering of that single value. Storing each attendee's local time separately guarantees they diverge on the next rule change. Recurring events raise the same issue one level up. "Every weekday at 09:00 Berlin time" is a rule, not a list of instants. Materialising a year of occurrences into stored instants recreates the original problem for every one of them; store the rule plus the zone and expand it near the time. ## When the instant genuinely is the right thing This is not an argument against instants. Prefer an `Instant` when the fact is exact-time-shaped: audit logs, created/updated timestamps, message ordering, cache expiry, deadlines expressed as "90 minutes from now", and anything where two records must be comparable across zones. Those never need re-derivation, and storing them as wall-clock plus zone would add ambiguity for nothing. A mixed system usually ends up with both columns and an explicit rule about which fields are which — and that explicitness is the actual deliverable. The interviewer is checking whether you can articulate why the two cases differ, not whether you can recite an API.