S3.03.4Daylight-saving time transitiondesignresearch

Daylight-saving observance and transition dates are not uniform

Aliases: DST transition · time-zone rule · nonexistent local time · ambiguous local time

What it is

A daylight-saving time transition is an event in which a region's civil clock changes its UTC offset under a rule. Many regions do not observe DST; among those that do, start and end dates and offset changes are not uniform, and rules can change temporarily or permanently. The core design problem is not a user's “DST preference.” It is distinguishing an absolute instant, a zone-free local date-time, and an IANA time-zone identifier, then defining behavior for gaps and folds in local time.

Why it happens

When clocks jump forward, a range of wall times does not exist: a gap. When clocks move backward, a range occurs twice: a fold. Storing 2026-xx-xx 02:30 with a fixed UTC offset cannot say how to handle a gap or choose the earlier or later instant in a fold. The IANA Time Zone Database maps instants to civil time through region identifiers and versioned rules. When political authorities change zone boundaries, offsets, or DST policy, the instant corresponding to a future local time can change. “Every week at local 09:00” therefore differs semantically from “every 168 hours.”

Studying it

Build conversion fixtures by IANA zone and tzdb version. Cover zones without DST, forward and backward transitions, non-hour changes, temporary policy changes, participants in multiple zones, and recurrences crossing transitions. Assert the input local date-time, resolution policy, resulting instant, offset, and rendered label separately. Property tests can check instant→local→instant round trips; local→instant must explicitly expect zero, one, or two candidates. Usability studies should examine whether people understand choices for nonexistent and repeated times and whether notification and calendar updates set the right expectation.

Where it stops holding

A fixed offset such as UTC+08:00 is not a regional time zone and cannot express future rules; short abbreviations are often ambiguous. Tzdb updates both known history and predicted future, but early history can be incomplete and future law can change after an event is created. A confirmed one-off meeting usually commits to an instant, with place and zone used for display. A shop opening, class, or reminder recurring by local routine usually commits to a local date-time, zone, and recurrence rule. They require different recomputation policies. Language, nationality, and current UTC offset do not uniquely identify a time zone.

Applying it

  • Store the instant for a confirmed one-off event and retain its IANA zone for explanation and display. For a wall-clock recurrence, store local date-time, IANA zone, recurrence rule, and gap/fold policy.
  • Do not silently create a nonexistent time in a gap. Ask for another time or clearly apply a published policy such as shifting to the first valid time after the jump. In a fold, distinguish the earlier and later occurrence or show offsets for disambiguation.
  • Use maintained tzdb data rather than fixed offsets or abbreviations, and record the rule version used. After an update, recompute only wall-clock recurrences or local times that have not yet been fixed, according to the event's commitment semantics; preserve the instant of a confirmed one-off event. Produce a diff and notify participants whose event time changes.
  • Test create, edit, ordering, reminders, countdowns, and export immediately around real transitions in every supported region. Include client/server tzdb mismatch, offline stale data, and cross-zone viewing. When a client version is stale, make the versioned server resolution authoritative and show the difference before submission or block silent confirmation; check for duplicate execution, omission, and misordering.

Related

  • Same group: S3.03.1 Workdays and rest days vary by region · S3.03.2 Holiday dates move across calendar systems · S3.03.3 Marketing occasions cannot be copied unchanged across markets
  • Adjacent: S2.01.3 Regional preference for 12-hour and 24-hour time · V4.06 Time zones and response expectations
  • Search terms: IANA time zone · DST gap fold · instant local date-time

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/S3.03.4