Time zone research

How Daylight Saving Silently Breaks a Recurring Meeting

A recurring meeting looks stable because its time is stated in one zone. The instability is in the other zones: their offsets change on different dates, so the local time each participant experiences drifts even though nobody edited the event. We modelled a weekly meeting pinned to a fixed local time in one city and measured how far it moved for participants elsewhere across a full year.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

A recurring meeting is pinned to a fixed local time. When daylight saving changes, what actually happens to the other participants?

This research models a recurring meeting against the runtime's own time-zone database for 2026. It does not predict any specific organisation's calendar behaviour and does not claim all zones shift on the same date.

Try it on the anchor product: BeanNest Time /, BeanNest Time /meeting-planner/.

The model

We anchor a weekly meeting to a fixed local wall-clock time in a reference zone and step it through fifty-two weeks. For each occurrence we read the offset in the reference zone and in a target zone and record the difference. The metric is the spread: how many distinct shift values appear across the year.

The measured spreads

Against a Vancouver anchor, a London participant saw shifts of 420 and 480 minutes, a spread of 60. Berlin showed a spread of 60. Tokyo showed a spread of 60. Kolkata showed a spread of 60. Every one of these is a full hour of movement that no participant scheduled.

Sydney moved twice as far

The Sydney pairing showed three distinct shifts, 1020, 1080, and 1140 minutes, a spread of 120. The reason is hemispheric: Sydney observes daylight saving in the opposite half of the year from the northern zones, so a northern anchor crosses two independent shift events rather than one.

Why the drift is silent

A calendar stores the recurrence in one zone and renders it in others. When an offset changes, the stored value is still correct and the rendered value changes. Nothing in the interface reports that the meeting moved, because from the calendar's point of view nothing changed.

Zones with no transition at all

Three zones in our evidence set report zero transitions for the year: Kolkata at +05:30, Kathmandu at +05:45, and Phoenix. A meeting anchored to one of these zones does not drift for that zone's participants, which is a real and underappreciated scheduling advantage. Kathmandu and Chatham also show that offsets are not restricted to whole or half hours; Chatham moved between +13:45 and +12:45.

What to do with this

The measured conclusion is that a recurring meeting must be re-checked at each transition date, not at creation time. Our evidence file lists every transition with its from and to offset, so the dates that matter can be read directly rather than recalled.

Why the calendar cannot warn you

A recurring event is stored as a start instant plus a rule, and the rule is expressed in one zone. When an offset changes, the stored instant for each occurrence is still correct; what changes is how that instant renders in other zones. From the calendar's perspective nothing has been edited, so there is nothing to warn about. The drift is a rendering difference, and rendering differences are not events.

The three states a pairing can occupy

Two zones that both observe daylight saving are either both in standard time, both in daylight time, or split between them. The first two states produce one shift value, and the split state produces another. A year in which the zones change on different dates therefore visits three values, which is exactly what the Sydney pairing produced at 1020, 1080, and 1140 minutes.

Why the size of the drift is not the problem

A movement of sixty minutes is noticeable, but the harder problem is that it is silent and uneven. Some participants move and others do not, so a meeting that was carefully scheduled for a convenient hour becomes convenient for a subset. The measured spreads quantify that unevenness, which is why they are the useful output rather than a single drift figure.

How to check the dates that matter

The evidence file lists every transition with its exact instant and its before and after offsets, so the dates on which a given pairing crosses can be read directly. That is more useful than remembering a rule, because the crossing depends on two zones rather than one. The generator produces the list by sampling, so it reflects the database rather than a recalled pattern.

Why a stored instant is not enough for a repeat

A single meeting can be stored as an instant because it happens once. A repeating meeting needs a rule, and the rule refers to a local time in some zone. When that zone's offset changes, the instant for each future occurrence changes with it, which is correct behaviour and also the source of the drift. Storing only instants would freeze the schedule to the original offsets and break the recurrence instead.

How many participants a transition can affect

A transition in the anchor zone moves every occurrence for every participant, which is why the measured spread includes movement even for zones that never change offset. A transition in a participant's zone moves only that participant's occurrences. The two effects combine, which is why a pairing of two daylight-saving zones produces three states while a pairing with a no-transition zone produces two.

What the measured spreads are and are not

They are exact for the modelled year, anchor, and target pairings. They are not a prediction for a different year, because rules can change, and they are not a claim about a different anchor, because the crossing pattern depends on both zones. The guides present them as measured examples illustrating the mechanism, which is the strongest claim the evidence supports.

Why the transition list is the useful artifact

Remembering that a zone observes daylight saving does not tell you when it changes relative to another zone, which is what determines whether a schedule breaks. The evidence file lists each transition with its instant and both offsets, so a reader can identify the specific dates on which a pairing crosses and check the schedule around them. That is more actionable than a rule.

How to audit a schedule before a transition

Read the transitions list for the anchor zone and for each participant's zone, then compare the instants. Any pairing whose changes fall in different weeks will be split for part of the year, and the meetings during that split are the ones that move. Auditing means checking those specific weeks rather than reviewing the whole year, which is a much smaller task once the dates are listed.

Why a weekly cadence can straddle a transition

A transition occurs on a specific instant, so one weekly occurrence falls before it and the next falls after. A participant therefore experiences two different local times a week apart with no intervening change to the event. That single-week discontinuity is what a reader is looking for, and it is visible by comparing the shift value before and after the transition instant.

How the evidence file supports the audit

Each transition entry records the instant, the offset before, the offset after, and the delta, which is exactly the input an audit needs. Comparing two zones' entries gives the shift for the weeks on either side, so the affected meetings can be identified without computation. The file is a direct answer to the practical question rather than a description of the mechanism.

What the guide does not promise

It does not promise that every transition breaks every meeting, because a meeting outside working hours in both zones may remain acceptable. It promises that the movement is measured and identifiable, which lets a reader judge whether a particular meeting is affected. The distinction between measured movement and a broken schedule is stated so the guide does not overstate its conclusion.

First-party evidence and provenance

How we checked this

We derived every offset and transition from the runtime's own time-zone database by sampling the zone offset hourly across the calendar year, then modelled a weekly meeting pinned to a fixed local wall-clock time in a reference zone. The generator is in this repository and the evidence file is its output. For this guide we stepped a weekly meeting through fifty-two weeks against each target zone and recorded the distinct shifts and their spread, which is what makes drift a measured value rather than a described one.

Method: We derived every offset and transition from the runtime's own time-zone database by sampling the zone offset hourly across the calendar year, then modelled a weekly meeting pinned to a fixed local wall-clock time in a reference zone. The generator is in this repository and the evidence file is its output.
Environment: Node.js on a desktop workstation, using the bundled IANA time-zone data. No network call, no hard-coded offset table, and no user data.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/time/transitions-2026.json
tools/research-evidence/time/README.md