· Updated May 7, 2026 · TimeZoneMeet editorial team
Daylight saving time is the single most common reason that recurring meetings quietly break. Two or three weeks each spring and autumn, half of your calendar starts behaving in ways that feel mysterious — the same meeting suddenly shows up an hour earlier on someone's screen, a colleague turns up sixty minutes late, an automated reminder fires in the middle of the night. None of that is mysterious once you know what's happening underneath, but the failure mode is so common that we wrote this post to walk through it from first principles.
What DST actually does
A common misconception is that DST changes a city's time zone. It does not. The time zone of New York is America/New_York all year long; the time zone of Paris is Europe/Paris all year long. What changes is the offset from UTC that each zone produces at any given moment. America/New_York is UTC−5 in winter (Eastern Standard Time) and UTC−4 in summer (Eastern Daylight Time). Europe/Paris is UTC+1 in winter (Central European Time) and UTC+2 in summer (Central European Summer Time).
Every modern calendar tool — Google Calendar, Outlook, Apple Calendar — knows these rules. When you create an event "every Tuesday at 09:00 New York time," the calendar stores the rule, not the offset. On any given Tuesday, it asks the operating system or its embedded tz database what UTC offset America/New_York currently produces, and converts to UTC for storage and to each viewer's local zone for display. That is why DST does not usually break the underlying invite. What it breaks is the wall-clock relationship between two people in different zones.
Why a recurring meeting "drifts"
Consider a weekly meeting between New York and Paris, scheduled for "Tuesday 09:00 ET / 15:00 CET" in mid-winter. The two cities are five hours apart. On March 8, 2026, the US springs forward; New York moves to UTC−4. Paris is still on UTC+1, because Europe does not spring forward until March 29. From March 8 through March 28 — three weeks — New York and Paris are only four hours apart, not five. The same Tuesday meeting at 09:00 ET is now 14:00 CET, not 15:00.
Whose calendar shows the change depends on how the meeting was created. If the New York organizer scheduled the meeting in their own zone (the default in most tools), the meeting stays at 09:00 ET and the Paris attendees see it move from 15:00 to 14:00. If the Paris organizer scheduled it, the meeting stays at 15:00 CET and the New York attendees see it move from 09:00 to 10:00. If the meeting was scheduled in UTC, both sides see it move on their wall clocks. None of these is a bug in the calendar tool; all of them are correct behaviour given the input. They are also all surprising, every time, to whichever side experiences the shift.
Then on March 29, Europe springs forward, both cities are on summer offsets, and the gap widens back to five hours. The meeting "settles" again — but anyone who got used to the temporary slot during those three weeks gets surprised a second time.
The 2026 transition calendar
For most teams, four dates matter:
- Sunday March 8, 2026 — United States and Canada begin daylight saving time at 02:00 local. Most of the country is affected; Arizona (except the Navajo Nation) and Hawaii do not observe DST.
- Sunday March 29, 2026 — most of the European Union, the United Kingdom, and Norway begin summer time at 01:00 UTC.
- Sunday October 25, 2026 — Europe ends summer time at 01:00 UTC.
- Sunday November 1, 2026 — United States and Canada end daylight saving time at 02:00 local.
The two "shoulder" periods — March 8–28 and October 25–31 — are when US ↔ Europe meetings drift by an hour. If your team has a recurring US ↔ Europe meeting, the right defensive move is to put a calendar reminder on each transition date and re-verify the next two instances of the meeting.
Regions that don't observe DST
If everyone in your team is in a region that does not observe DST, you do not have a drift problem at all — only an offset problem with whichever side does. Among the regions with no DST in 2026:
- India, Pakistan, Bangladesh, Sri Lanka
- China, Hong Kong, Singapore, Malaysia, Taiwan, Vietnam, Thailand, Indonesia
- Japan and South Korea
- Most of Africa
- Most of South America (Brazil ended DST permanently in 2019)
- The US states of Arizona and Hawaii
- Iceland, Russia, Belarus, Turkey
This means that the relationship between San Francisco and Bangalore, for example, changes twice a year by an hour even though Bangalore itself is on a fixed offset. That can feel counter-intuitive: nothing changed in India, yet your standup just shifted.
Calendar storage: the part that matters most
Every recurring meeting has an answer to one question: which time zone is the rule stored in? In Google Calendar, the storage zone is whatever zone was selected when the event was created (usually the organizer's primary zone, unless they explicitly changed it). In Outlook, it is the organizer's zone unless they enable the time zone selector. In Apple Calendar, it is the device's current zone unless time-zone support is on.
The storage zone is the side that does not drift. Everyone else's wall clock can move during DST shoulders. So the question to ask before scheduling a recurring meeting is: which side do we most want to keep on a stable wall clock? For a US-organized meeting with one Paris attendee, storing in New York time keeps the New York side stable and the Paris side gets a temporary 14:00 slot. For a Paris-organized meeting with one New York attendee, storing in Paris time keeps the Paris side stable and New York gets a temporary 10:00 slot. There is no "correct" answer; just an explicit one.
What to do, concretely
- Always write the zone with the time in invite descriptions. "Tue 09:00 New York" beats "Tue 09:00 EST" because EST has different meanings in different audiences (see why abbreviations are ambiguous).
- Add a UTC anchor for any meeting that crosses continents. UTC never observes DST, so the UTC time is the one anchor that does not move.
- Set transition reminders on the four 2026 dates above. When the reminder fires, open the next two weeks of recurring cross-region meetings and verify the wall-clock times on both sides.
- Decide storage zone explicitly for any recurring series. If you do not, the storage zone is whichever zone was active on the device of whoever created the event — which may not be anyone's primary zone if they were travelling.
- For automated reminders or paged on-call rotations, do not anchor to a local zone. Anchor to UTC. The point of an alert is to fire at a specific moment in time, not to track a city's wall clock.
Permanent DST proposals
The US Congress has periodically debated making DST permanent (the "Sunshine Protection Act" was passed by the Senate in 2022 but has not become law). The European Union voted in 2019 to end seasonal clock changes but has not implemented it. As of mid-2026, both regions still observe DST as they have for decades. We update this post when the rules actually change, not when proposals are introduced.
Verification with TimeZoneMeet
Open TimeZoneMeet, type a city, and the result shows the city's current local time and IANA zone. If you are debugging a confused recurring meeting, run a lookup for both cities side by side and compare against what your calendar is showing. The Schedule tool extends this by computing meeting windows that respect both sides' working hours, with the current offsets baked in — so you do not have to do the DST math by hand.