Recurring events that cross DST must recompute local clock time, not a fixed offset

What it is

“Every Tuesday at ten” names ten on that city’s wall, not “the first meeting’s instant plus seven days”. Recurring events that cross a DST boundary must be recomputed from the local clock face. The week of entering or leaving daylight saving, the absolute instant that ten names jumps by an hour. If what was stored is a frozen UTC offset, the wall becomes nine or eleven, and people still think they booked ten. That the clock face is discontinuous on the transition night is a different confusion. This is only about how a recurrence expands into occurrences across that boundary.

Why it happens

A recurrence can expand in two ways. One takes the first occurrence’s absolute instant and adds a frozen interval (seven 24-hour days); the offset is iced inside the first. DST makes a local day 23 or 25 hours long, and the frozen interval no longer hits ten on the wall. The other asks “zone + local clock face + date” for an instant every time: ten remains ten, and the instant jumps. What people book is a cell on the wall, not a fixed number of seconds of earth rotation, so expansion has to take the second path.

The boundary also produces gaps and overlaps: a spring clock time that never occurs, an autumn clock time that occurs twice. Recompute does not erase those cells. It picks, from the rule table, a legal instant for this occurrence (commonly “still local ten, landing on the post-transition offset”), and if it cannot land, refuses or moves to the nearest legal cell — rather than adding seven days on the pre-transition offset.

Where it stops holding

A one-shot event has no recurrence to expand; store the instant, and do not treat it as a rule. A reminder that repeats on an absolute interval (a dose every 24 hours, whatever the wall says) should keep the frozen interval; recomputing the wall would break dosing rhythm. A series that spans many zones (an all-hands across the globe) has no shared wall; it needs “which zone’s clock face is canonical”, or “ten in each participant’s local”, expanded per person. If the rule table lacks that year’s DST data, recompute silently uses the wrong offset; the bug looks like the old frozen-offset failure and is actually a stale table.

Applying it

• When storing a recurrence, store together: a zone identifier, a local clock face (Tuesday 10:00), a period. Expand each occurrence by asking the rule table of that date for the instant.
• Do not default “next = last instant + 7×24h” across a DST-observing zone.
• When expansion lands in a gap or overlap, pick a legal instant by product rule or ask the person to confirm. Do not keep the old offset.
• How to check: in a DST-observing zone, create a “every Tuesday 10:00” series that crosses the spring transition. The occurrence after the transition should still read 10:00 locally, and its absolute instant should sit an hour away from the previous week. A frozen-UTC expansion, as control, should misread as 9:00 or 11:00 locally. A every-24-hours dose reminder should not recompute with the wall.

Related

• Same group: I4.08.1 Store time in an absolute standard; convert to local only at display · I4.08.3 Time-zone rules change with politics; year-spanning conversion cannot assume a frozen map · I4.08.4 After the user changes zone, past records must keep the same absolute instant
• Nearby: I4.05 Time zones · I4.06 Countdowns and deadlines
• Search terms: recurring DST · wall time · timezone identifier