Calendar behaviour · Tech
Decide what the next occurrence must preserve
The same wall-clock hour and the same elapsed interval are different scheduling requirements.
- A local hour can require a longer waitIn our Warsaw calculation, 09:00 on 24 October and 09:00 on 25 October 2026 are 25 elapsed hours apart.
- One city owns the recurring hourA Monday meeting fixed at 15:00 in Warsaw appears at 09:00, 10:00 and 09:00 in New York across three selected weeks.
- Check the dates around both clock changesA correct first invitation does not establish that the later occurrences preserve the intended local hour.
A team agrees to meet at the same time every Monday. For months, the Warsaw participant sees 15:00 and the New York participant sees 09:00. Then one invitation appears an hour later in New York. Nobody necessarily edited the series. The software may be preserving exactly the promise that the organizer gave it.
The hidden decision is whose clock gets to stay familiar. “Every day,” “every 24 hours” and “every Monday at 15:00 in Warsaw” can agree for a long stretch before producing different appointments. We generated four small schedules to expose that difference, using the autumn 2026 clock changes in Europe/Warsaw and America/New_York. The result is a practical check for recurring events, not a claim that a particular calendar app is broken.
The two daily schedules agree until the clocks move
Start with a harmless personal reminder at 09:00 in Warsaw on Saturday, 24 October 2026. Define one schedule by the local calendar: find 09:00 in Warsaw on each following date. Define another by elapsed time: add exactly 86,400,000 milliseconds to the first instant for each new occurrence.
Our first schedule asks a named time zone to interpret each date. Our second performs fixed arithmetic. Both begin at the same instant, 07:00 UTC on 24 October. Their next results differ.
Three mornings from the same starting point
| Date in 2026 | 09:00 in Warsaw | Every 24 hours |
|---|---|---|
| 24 October | 09:00 · 07:00 UTC | 09:00 · 07:00 UTC |
| 25 October | 09:00 · 08:00 UTC | 08:00 · 07:00 UTC |
| 26 October | 09:00 · 08:00 UTC | 08:00 · 07:00 UTC |
Warsaw’s offset changes from UTC+02:00 to UTC+01:00 on 25 October under the EU rules recorded for Europe/Warsaw in IANA’s time-zone data. Moving the clock back means that reaching the same local hour on the following date takes an additional elapsed hour.
Neither schedule is inherently defective. A process that must wait 24 elapsed hours has a different requirement from a morning planning session that should remain at 09:00. The error is silently replacing one requirement with the other. This example concerns civil-time rules; the physical clock-rate differences in our explanation of timekeeping on the Moon are a separate problem.
The organizer chooses whose morning moves
Now make the reminder a weekly meeting, with an hour that works in both cities. Fix it to Monday at 15:00 in Warsaw. We computed three occurrences: 19 October, 26 October and 2 November 2026. Warsaw stays at 15:00 throughout. New York displays 09:00, then 10:00, then 09:00.
The middle week matters because Warsaw changes on Sunday, 25 October, while New York changes on Sunday, 1 November. The IANA US rules used by America/New_York place the autumn transition on the first Sunday in November. Across these selected Mondays, the cities’ difference is therefore six hours, five hours and six hours.
Reverse the decision and the inconvenience changes sides. Our fourth schedule fixes Monday at 09:00 in New York. On the same three dates, Warsaw sees 15:00, 14:00 and 15:00. The supposedly neutral choice of an event time zone determines which participant absorbs the temporary shift.
That is a coordination decision a calendar cannot make for the group. If a New York school run makes 09:00 non-negotiable, anchoring the series in Warsaw protects the wrong constraint. If a Warsaw room booking must remain at 15:00, a New York anchor may be equally unsuitable. When both local hours are essential, the team needs a deliberate exception, a different meeting arrangement or an agreed cancellation for the affected occurrence.
A stored instant does not preserve the recurrence rule
Saving the first appointment as a UTC timestamp identifies when that appointment happens. It does not, on its own, record how to generate the next one. The two daily schedules above share their first UTC instant and then diverge. An implementation needs the recurrence meaning as well as the first timestamp.
The iCalendar standard recommends a local start time with a time-zone reference when recurring instances should retain the same local hour through zone changes. It also distinguishes such values from UTC times and from “floating” local times without a zone reference. A floating hour can follow the recipient’s local setting; it is a poor assumption for a shared simultaneous meeting.
Google’s Calendar API documentation makes the recurring-series requirement concrete: it requires one specified time zone to expand a recurring event. That documentation supports the meaning of the field. It does not establish that we imported an event into Google Calendar, observed its interface or tested its reminders.
A numeric offset such as +02:00 tells you how a local reading relates to UTC at that moment. A named zone such as Europe/Warsaw supplies date-dependent rules. Carrying October’s offset forward as if it were the city’s permanent identity loses the information that produced the table.
The same need for explicit time context appears in Google Ads conversion-adjustment timestamps, where the occurrence time belongs to a particular change. A recurrence adds another question: how should later occurrences be derived? And if the display changes between server and browser, time-dependent React hydration deserves its own check. Correct recurrence arithmetic and consistent rendering are separate things to verify.
Inspect three occurrences before accepting the series
For a Warsaw–New York series spanning autumn 2026, inspect 19 October, 26 October and 2 November, or corresponding occurrences around those transition dates. Looking at the first invitation alone misses the disagreement by construction.
- Write down the protected hour. State the event’s anchor city and local time, or state that a fixed elapsed interval is the requirement. “Same time” is insufficient.
- Open the occurrences on both sides. Compare the time shown in each participant’s city before the first change, between the changes and after the second. Use the actual calendar application the group will use.
- Agree on the shifted occurrence. If one participant’s local hour moves, decide whether that is acceptable before editing the whole series. Recheck any deliberate exception in both cities.
For developers, retain a fixture that demonstrates both promises. A local-09:00 test should expect a 25-hour interval across Warsaw’s October change. A fixed-24-hour test should expect the displayed local hour to move to 08:00. A test that demands both a constant local hour and a constant elapsed interval is asking for incompatible outcomes on that transition.
The calculation used daytime hours deliberately. Nonexistent springtime hours, repeated autumn hours, travel between zones and notification delivery need additional cases. Time-zone rules can also change, so an old successful fixture does not certify every future appointment or every location.
The useful question to settle with the organizer is specific: when the cities disagree for a week, whose local hour should remain unchanged? Once that decision is explicit, the shifted invitation can be evaluated against an agreement instead of being mistaken for an unexplained calendar error.
Primary documentation and calculation method
Sources checked 13 September 2026. Our local calculation used Node.js 22.14.0, ICU 76.1 and its bundled tz data 2024b. For the two zones and selected dates, we cross-checked the applicable transition rules against the linked IANA 2026c source files; we do not claim that the runtime’s entire time-zone database was current.
For each requested local date and hour, the script enumerated nearby UTC instants at one-minute resolution and retained the unique match produced by Intl.DateTimeFormat in the named zone. It compared those matches with fixed 24-hour addition, then repeated the weekly calculation with Warsaw and New York as alternative anchors. Assertions verified all table values, the 25-hour interval and both cross-city sequences. This is an executed calculation with synthetic schedules, not a calendar-client, ICS-import or notification test.
