The meeting did not move. The clocks did.
A recurring international meeting can look stable in one calendar and still move for everyone else. A New York team may create a weekly meeting for 9:00 AM every Monday. For them, the meeting stays at 9:00. For colleagues in London, Madrid, Dubai, Tokyo, or Sydney, the same invitation can appear one hour earlier or later during the daylight saving gaps between regions.
The problem is not that calendar apps are broken. The problem is that a recurring meeting has to answer a hidden question: is the meeting anchored to a local clock time in one city, or is it anchored to a fixed UTC time? Those are different promises.
If the meeting is anchored to 09:00 America/New_York, New York keeps 9:00 and UTC moves when New York changes clocks. If the meeting is anchored to 14:00 UTC, UTC stays fixed and New York moves from 9:00 to 10:00 after the spring change. Both choices can be correct. The wrong choice is not writing the rule down.
America/New_York. Times were calculated with IANA time zone rules for 2026. Future years should be rechecked because daylight saving laws can change.
Why the shift happens
Daylight saving rules are local laws, not a global switch. In 2026, the United States starts daylight saving time on Sunday, March 8 and ends it on Sunday, November 1. The European Union moves on the last Sunday in March and the last Sunday in October. Sydney follows a southern-hemisphere pattern, ending daylight saving in April and starting again in October. Dubai and Tokyo do not change clocks in this example.
That creates mismatch windows. For a few weeks, New York and Europe are not on their usual offset. Later, Sydney changes while the northern hemisphere is moving the other way. The meeting is still the same instant for everyone, but the local clock labels drift.
A 9:00 AM New York meeting in spring 2026
The spring transition is where many teams first notice the problem. New York moves one hour earlier relative to UTC on March 8, 2026. London and Madrid do not move until March 29, 2026. Sydney then leaves daylight saving on April 5, 2026.
Mon, Mar 2 winter baseline
Mon, Mar 9 US changed first
Mon, Mar 30 Europe catches up
Mon, Apr 6 Sydney changes
The same meeting changes three times for some participants in just over a month. London moves from 14:00 to 13:00, then back to 14:00. Madrid moves from 15:00 to 14:00, then back to 15:00. Sydney moves from Tuesday 01:00 to Tuesday 00:00, then to Monday 23:00 after its own daylight saving period ends.
The autumn shift is different
The autumn transition is not a perfect mirror. Europe changes back on October 25, 2026. New York changes back on November 1, 2026. That creates a one-week window where a New York-anchored 9:00 meeting appears one hour earlier in London and Madrid than it did the week before.
Mon, Oct 19 before Europe changes
Mon, Oct 26 Europe changed first
Mon, Nov 2 winter pattern returns
What if the meeting is fixed to UTC instead?
Some technical teams prefer UTC because it is unambiguous. That can be the right choice for incident reviews, releases, logs, trading systems, broadcast schedules, or server operations. But a fixed UTC meeting does not protect local work hours. It moves the pain to the people whose civil clocks change.
14:00 UTC on Mar 2 before US DST
14:00 UTC on Mar 9 after US DST
14:00 UTC on Mar 30 after EU summer time
14:00 UTC on Nov 2 back to winter
This is why "just use UTC" is not always enough for humans. UTC is excellent for timestamps. It is not automatically fair for a standing meeting.
How to diagnose your own calendar invite
You do not need to guess how a recurring invite is anchored. Open one occurrence before a daylight saving change and one occurrence after it, then compare the organizer city, UTC, and one remote city.
The meeting is probably attached to an IANA city zone such as America/New_York. Other regions can move during transition weeks.
The instant is stable worldwide, but local working hours shift for places that enter or leave daylight saving time.
Short labels are fragile. EST can mean a fixed offset, a winter label, or a casual shorthand for Eastern time.
The practical rule for calendar invites
For a recurring team meeting, write 09:00 America/New_York, 15:00 Europe/Madrid, or the actual owner city. A city-based IANA zone carries DST rules.
For logs, releases, incidents, trading, monitoring, or one-off global events, UTC removes ambiguity.
For deadlines, add date, time, city zone, and cut-off. "Friday at 5" is incomplete if people are in different places.
For a real recurring meeting, the safest invitation text is redundant on purpose:
Weekly product sync: Mondays at 09:00 America/New_York. Local times may shift for other regions during daylight saving transition weeks.
If fairness matters, rotate the meeting time or review it twice a year. Use a meeting planner before the March and October/November transitions, and use a time zone converter when sending one-off times. The world clock helps sanity-check what "now" means for each participant.
Method notes
- The example uses the IANA zones
America/New_York,Europe/London,Europe/Madrid,America/Los_Angeles,Asia/Dubai,Asia/Tokyo, andAustralia/Sydney. - The selected dates are Mondays around the 2026 daylight saving transitions: March 2, March 9, March 30, April 6, October 19, October 26, and November 2.
- Times are shown for the local civil time in each location. Future laws can change, so re-check important meetings when planning far ahead.