For an appointment scheduled months ahead, why is storing a UTC instant plus a fixed offset not enough?
answer
- one number versus a set of rules
- past is history, future is a prediction
- transitions and legal changes move offsets
- store local time with the zone identifier
- some local times never happen, some twice
basics
~20 sAn offset is a snapshot of one moment's rule. Zone offsets change at daylight-saving transitions and when governments rewrite the rules, so a future commitment must store the local date-time plus the zone identifier, converted to an instant at use.
solid answer
~50 sTwo different facts hide behind the same-looking data. An **instant plus an offset** records what happened: the moment on the timeline and the local view at that moment, which no later rule change may move. A future commitment is not that - it is an intention expressed in **wall-clock time in a place**, and its instant is a prediction derived from today's rules. Those rules change: daylight-saving transitions shift the offset twice a year, and governments revise zone rules with little notice, shipped as time-zone data updates. So a scheduled item stores the **local date-time plus the zone identifier**, with the instant computed at use, while a past event stores the instant with the offset it had. Transitions also create local times that never occur and ones that occur twice, so the entry path needs a documented rule for gaps and overlaps.
go deeper
Recall that an offset is a single number for one moment while a zone identifier names rules that change over time, and that the two are not interchangeable when a date is in the future.
Explain why a past event stores an instant plus its offset while a future local commitment stores the local date-time plus the zone identifier, and what a daylight-saving gap or overlap does to a local reading.
Show the operational side: a rules update invalidates precomputed instants, components must share one data vintage, and gap and overlap resolution needs a written policy applied in one place.
Set the boundary contract for the whole product - which payloads carry instants, which carry local time with a zone - and own the recomputation and rollout plan for time-zone data updates across services.
## Two facts that look like one Writing down a time can mean two quite different things. - **A record of something that happened.** The fact is a point on the timeline. The right storage is an **instant** - conventionally in `UTC` - and, if the local view matters for display or audit, the **offset that was in force at that moment**. Nothing that happens later may change it. - **A commitment about something that will happen.** The fact is a **wall-clock time in a place**: nine in the morning, where the user is. The corresponding instant does not exist yet as a fact; it is computed from the rules that will be in force then, and today we only have the rules we currently know. Collapsing the second into the first - computing the instant once, at save time, and storing only that - is the defect. The computation was correct when it ran and silently becomes wrong when the rules change. ## Why an offset expires An **offset** is a number: the difference from `UTC` at one moment. A **zone identifier** names a set of rules that produce offsets over time. The relationship is one-way - the rules give you the offset, and the offset never gives you back the rules. The offset for a given zone changes for two reasons: 1. **Daylight-saving transitions.** In zones that observe them, the offset shifts twice a year on dates fixed by the rules. A future local time on the other side of a transition has a different offset from today's. 2. **Rule changes.** Governments move transition dates, adopt or abandon daylight saving, or redefine a zone outright, sometimes weeks before it takes effect. These arrive as updates to the shared time-zone data that platforms carry, and they apply to future dates. | what you are recording | store | survives a rules change | |---|---|---| | an event that already happened | instant, plus the offset then in force | yes - it is history | | a future local commitment | local date-time plus zone identifier | yes - recomputed at use | | a future commitment as a precomputed instant | instant only | no - silently drifts | | a machine deadline or timeout | instant | yes - no wall clock involved | Note the last row: not everything future is wall-clock. A retry deadline five minutes out is genuinely an instant, and attaching a zone to it would be noise. The distinction is whether a human agreed to a clock reading. ## Gaps and overlaps Transitions do not only shift the offset; they make the local timeline non-continuous. - A **gap** occurs when clocks jump forward: an hour of local time does not exist that day. A user who asks for a meeting inside it has named a time that never happens. - An **overlap** occurs when clocks fall back: an hour of local time happens twice, so a local reading maps to two instants. Both need a **written policy**, applied in one place: shift a gap forward by its length or reject the input at entry and ask the user; take the earlier or the later occurrence of an overlap. The failure mode is not choosing - each library has a default resolution, and different parts of a system end up on different ones. ## At the request boundary This shapes what the interface carries. An instant is enough for anything historical or machine-scheduled. Anything a user agreed to in local terms has to carry the **local date-time and the zone identifier** as separate parts, so the receiving side can recompute rather than re-derive a zone from an offset. On the way out, rendering needs the resolved zone for the reader, which may not be the zone the commitment was made in - a meeting set in one zone still has to display correctly to a participant in another, and that is exactly why both the zone of record and the reader's zone must be available. ## Operating a rules update A rules update is an operational event, not just a dependency bump: - Anything that **precomputed instants from future local times** - scheduler rows, reminder queues, cached renderings - is stale and needs recomputation after the update. - Components must run on **consistent time-zone data**; two services on different vintages will disagree about the same future local time, which is a miserable defect to reproduce. - Recurring items are the sharpest case: a series defined as a local time repeats at a shifting instant, so materializing the series as instants far ahead guarantees drift after the next transition or rule change.
- When is storing an instant plus an offset the right choice?When you are recording something that already happened. The instant fixes the moment and the offset preserves the local view at that moment, and no later rules update may retroactively move a past event. Keeping the zone identifier alongside is still useful for display, but correctness no longer depends on it.
- What should happen when a scheduled local time falls into a daylight-saving gap?Apply a documented policy rather than whatever a library default picks: shift forward by the length of the gap, or reject the input at entry and make the user choose. For an overlap, decide whether the earlier or later occurrence wins. The rule matters less than having one rule, applied in one place.
- Why do recurring events suffer most from precomputed instants?A series defined as a local time repeats at a wall-clock reading, not at a fixed interval on the timeline. Materializing many occurrences as instants bakes in today's offsets, so every occurrence past the next transition or rules change is an hour off until someone recomputes the series.
A fixed offset is a photograph of a clock face; a zone identifier is the rulebook that clock follows. When the rules change, the photograph still shows the old time.
saying these in an interview costs you the question
- Says storing everything in UTC is sufficient, including future local commitments.
- Treats a numeric offset as a stable identity for a zone.
- Assumes zone rules are fixed once a release has shipped.
- Ignores that some local times never occur and others occur twice.
- Recomputes nothing after a time-zone data update, leaving precomputed instants stale.
- Attaches a zone to machine deadlines that were never wall-clock commitments.