How to Avoid DST Mistakes in Global Meetings

Quick Answer
**Quick Answer: [daylight saving time](/articles/what-is-daylight-saving-time) causes meeting errors because countries change clocks on different dates—or do not change at all. The US shifts on the second Sunday of March; the EU shifts on the last Sunday of March; Australia shifts in April; Japan, I
Why DST Causes So Many Meeting Errors
Daylight saving time is a relic of early 20th-century energy policy that persists in roughly 70 countries worldwide. For global teams, it is not the time change itself that creates problems—it is the asymmetry of the change.
When every country changed clocks on the same day, the time difference between New York and London would always shift by one hour at the same moment. The gap would change, but it would change for everyone simultaneously. No confusion.
In reality, the US changes on the second Sunday of March, the EU changes on the last Sunday of March, Australia changes in early April, and major economies like India, China, Japan, and Singapore never change at all. This means that between the first country's shift and the last country's shift, the time differences that teams rely on for daily meetings are temporarily wrong.
The Scale of the Problem
Consider a team with members in New York, London, and Singapore. Their normal time differences look like this:
| Pair | Winter (Jan–Mar) | Summer (Apr–Oct) |
|---|---|---|
| New York – London | 5 hours | 4 hours |
| New York – Singapore | 13 hours | 12 hours |
| London – Singapore | 8 hours | 7 hours |
But during the mismatch period in March—when the US has moved forward but the UK has not—the differences are:
| Pair | Mismatch Period (mid-March) |
|---|---|
| New York – London | 4 hours (off by 1 hour from winter norm) |
| New York – Singapore | 12 hours (off by 1 hour from winter norm) |
| London – Singapore | 8 hours (unchanged—UK hasn't moved yet) |
A recurring meeting set for "9:00 AM New York / 2:00 PM London" under winter time now falls at "9:00 AM New York / 1:00 PM London" during the mismatch. If the London participant relied on the old offset, they show up an hour late.
Countries That Observe DST vs. Don't
Understanding which of your team's locations observe DST—and when—is the foundation of error-free scheduling.
Major Countries That Observe DST
| Country/Region | Spring Forward | Fall Back | Notes |
|---|---|---|---|
| United States | 2nd Sunday March | 1st Sunday November | Except Arizona (most of state) and Hawaii |
| Canada | 2nd Sunday March | 1st November | Same as US; Saskatchewan does not observe |
| United Kingdom | Last Sunday March | Last Sunday October | |
| European Union | Last Sunday March | Last Sunday October | Uniform across EU member states |
| Australia | 1st Sunday October | 1st Sunday April | Only SE states (NSW, VIC, ACT, SA, TAS); not QLD, WA, NT |
| New Zealand | Last Sunday September | 1st Sunday April | |
| Brazil | Not observed | Not observed | Abolished DST in 2019 |
| Mexico | Not observed | Not observed | Abolished DST in 2022 (border regions may still align with US) |
Major Countries That Do NOT Observe DST
| Country | Time Zone | UTC Offset | Year-Round |
|---|---|---|---|
| China | CST | UTC+8 | No DST since 1991 |
| India | IST | UTC+5:30 | Never observed DST |
| Japan | JST | UTC+9 | No DST since 1951 |
| Singapore | SGT | UTC+8 | No DST since 1982 |
| South Korea | KST | UTC+9 | No DST since 1988 |
| Indonesia | WIB | UTC+7 | Never observed DST |
| Saudi Arabia | AST | UTC+3 | Never observed DST |
| UAE | GST | UTC+4 | Never observed DST |
The Implication
If your team spans a DST-observing country and a non-DST country, the time difference between them changes twice a year. This is the root cause of most DST-related meeting errors.
The Mismatch Problem: 2–3 Weeks of Chaos Per Transition
The mismatch between US and EU DST dates is the most impactful for global business. Here is what happens each year:
Spring Transition
-
US springs forward (2nd Sunday of March): The US moves one hour ahead. The EU has not changed yet. For the next 2–3 weeks, the US–Europe gap is one hour different from the winter norm.
-
EU springs forward (last Sunday of March): The EU moves one hour ahead. Now both regions are on summer time, and the gap returns to its summer value.
Fall Transition
-
EU falls back (last Sunday of October): The EU moves one hour back. The US has not changed yet. For the next week, the US–Europe gap is one hour different from the summer norm.
-
US falls back (1st Sunday of November): The US moves one hour back. Now both regions are on winter time, and the gap returns to its winter value.
The spring mismatch lasts approximately 2–3 weeks. The fall mismatch lasts about 1 week. During these periods, the time differences that teams have internalized are temporarily wrong.
Mismatch Duration by Year
| Year | US Spring Forward | EU Spring Forward | Mismatch Days | US Fall Back | EU Fall Back | Mismatch Days |
|---|---|---|---|---|---|---|
| 2025 | March 9 | March 30 | 21 days | November 2 | October 26 | 7 days |
| 2026 | March 8 | March 29 | 21 days | November 1 | October 25 | 7 days |
| 2027 | March 14 | March 28 | 14 days | November 7 | October 31 | 7 days |
Note: The EU has periodically discussed abolishing DST entirely, which would create permanent mismatches. As of 2026, DST remains in effect across EU member states, but this is worth monitoring.
Spring Forward / Fall Back: What Actually Happens to Your Schedule
Spring Forward (Clocks Move Ahead One Hour)
When a region springs forward, 2:00 AM becomes 3:00 AM. The day loses one hour. For meetings, this means:
- A recurring meeting that was at 9:00 AM local time is still at 9:00 AM local time after the transition. The clock display has not changed.
- However, the UTC equivalent of that 9:00 AM local time has shifted. A 9:00 AM EST meeting was at UTC 14:00; after springing forward, 9:00 AM EDT is at UTC 13:00.
- For participants in a different time zone who have not yet changed their clocks, the meeting has effectively moved by one hour in their local time.
Example: A weekly call at 9:00 AM EST / 2:00 PM London. On March 8, 2026 (US spring forward), the US moves to EDT. The same meeting is now 9:00 AM EDT / 1:00 PM London (because London has not changed yet). A London participant who saved "2:00 PM" in their calendar arrives one hour late.
Fall Back (Clocks Move Back One Hour)
When a region falls back, 2:00 AM becomes 1:00 AM. The day gains one hour. The same logic applies in reverse:
- A 9:00 AM local meeting stays at 9:00 AM local time.
- The UTC equivalent shifts the other way. A 9:00 AM EDT meeting was at UTC 13:00; after falling back, 9:00 AM EST is at UTC 14:00.
- Participants in a zone that has not yet changed their clocks find the meeting has moved one hour earlier in their local time.
Example: A weekly call at 9:00 AM EDT / 2:00 PM London. On October 25, 2026 (UK fall back), the UK moves to GMT. The same meeting is now 9:00 AM EDT / 1:00 PM GMT (because the US has not changed yet). A London participant who expected the call at 2:00 PM arrives one hour late.
The Danger Weeks: Specific Dates When Mismatches Occur in 2026
These are the dates in 2026 when time differences between regions will be temporarily off by one hour. Mark them on your team calendar.
| Danger Period | Affected Pair | Normal Difference | Temporary Difference | Who Is Affected |
|---|---|---|---|---|
| March 8–28, 2026 | US East Coast – London | 5h (winter) | 4h | US has moved, UK has not |
| March 8–28, 2026 | US East Coast – Singapore | 13h (winter) | 12h | US has moved, Singapore never moves |
| March 8–28, 2026 | US East Coast – India | 10h30m (winter) | 9h30m | US has moved, India never moves |
| March 29 – ongoing | London – Singapore | 8h (winter) | 7h | UK has moved, Singapore never moves |
| March 29 – ongoing | London – India | 5h30m (winter) | 4h30m | UK has moved, India never moves |
| October 25–31, 2026 | US East Coast – London | 4h (summer) | 5h | UK has moved back, US has not |
| October 25–31, 2026 | London – Singapore | 7h (summer) | 8h | UK has moved back, Singapore has not |
What to Do During Danger Weeks
-
Send a reminder at the start of each danger week with the corrected meeting times for all participants.
-
Double-check your calendar. Open each recurring meeting and verify the time displays correctly in every participant's time zone.
-
Start meetings with a time check. "Before we begin, can everyone confirm it's [time] where they are?" This takes 10 seconds and catches any errors.
-
Be extra patient. Expect that someone will join late or early during danger weeks. Do not penalize it—fix the schedule instead.
How to Audit Your Recurring Meetings
A DST audit is a systematic review of all recurring meetings to verify they display correctly across time zone transitions. You should do this twice a year: once in the week before the US spring forward and once in the week before the EU fall back.
Step-by-Step Audit Process
-
List all recurring meetings that include participants in more than one time zone. You can generate this from your calendar by filtering for meetings with attendees in different regions.
-
For each meeting, record the following:
-
Meeting name
-
Current start time (in the organizer's time zone)
-
Current start time (in UTC)
-
Current start time (in each participant's time zone)
- Advance your calendar to a date after the next DST transition. Check each meeting:
-
Does the time display correctly in the organizer's time zone?
-
Does the time display correctly in each participant's time zone?
-
Has the UTC value changed? (It should not, if the meeting is stored in UTC.)
-
Flag any discrepancies. If a meeting time shifts unexpectedly, it likely means the meeting was stored in local time rather than UTC. Re-create the meeting with the correct UTC reference.
-
Send corrections. If you find errors, update the meeting and notify all participants. Do not assume they will notice the change.
Audit Template
| Meeting Name | Organizer TZ | Current Time (Organizer) | UTC Time | Participant 1 Time | Participant 2 Time | Correct After DST? |
|---|---|---|---|---|---|---|
| Weekly Standup | EST | 9:00 AM | 14:00 | 2:00 PM London | 7:30 PM IST | ☐ |
| Sprint Planning | EDT | 10:00 AM | 14:00 | 3:00 PM London | 7:30 PM IST | ☐ |
| 1:1 with Delhi | EST | 8:00 AM | 13:00 | 1:00 PM London | 6:30 PM IST | ☐ |
Best Practices for DST-Proof Scheduling
1. Store Everything in UTC
The single most important practice is to ensure your calendar stores recurring meeting times in UTC, not in a local time zone. When a meeting is stored in UTC, the calendar automatically adjusts the display for each participant's current time zone—including after DST transitions. Most modern calendar platforms (Google Calendar, Outlook 365, Apple Calendar) store meetings in UTC by default. However, some legacy systems and third-party scheduling tools do not. Verify your platform's behavior.
2. Always Include UTC in Written Communications
When you send meeting times in email, Slack, or documents, include the UTC offset. Example: "Standup at 9:00 AM EST (UTC-5) / 2:00 PM GMT (UTC+0) / 7:30 PM IST (UTC+5:30)." This eliminates ambiguity and gives everyone a reference point for conversion.
3. Never Manually Copy Meeting Times
If you are copying a meeting time from last week's calendar invite to create a new one during a danger week, stop. The offset may have changed. Use your calendar's recurring meeting feature or a scheduling tool that handles DST automatically.
4. Rotate Who Accommodates
During danger weeks, the team in the region that has not yet changed clocks may find the meeting has shifted to a less convenient time. Instead of asking the same team to always adjust, rotate who takes the inconvenient slot. This is especially important for US–India and US–Singapore teams where India and Singapore never change clocks.
5. Add a Buffer on Transition Days
On the day of a DST transition (and the day after), add a 15-minute buffer before and after any cross-time-zone meeting. This accounts for the inevitable confusion and ensures no one is rushed if they join at the wrong time.
6. Use Time Zone-Aware Scheduling Tools
Tools like Calendly, SavvyCal, and Doodle automatically handle DST when displaying availability across time zones. If you are manually coordinating meeting times, you are more likely to make a DST error. Use a tool.
Tools That Handle DST Automatically
| Tool | DST Handling | Best For |
|---|---|---|
| Google Calendar | Stores meetings in UTC; auto-adjusts display | Individual and team scheduling |
| Outlook 365 | Stores meetings in UTC; auto-adjusts display | Enterprise scheduling |
| Calendly | Detects participant time zone; adjusts availability display | Booking external meetings |
| SavvyCal | Multi-time-zone overlays with DST awareness | Scheduling across many zones |
| World Time Buddy | Visual time zone comparison with DST detection | Finding overlap windows |
| Timezone.io | Shows team members' current local times | Quick reference for distributed teams |
| Every Time Zone | Simple visual timeline across zones | Quick visual reference |
Important caveat: Even the best tools can fail if the user inputs the wrong time zone. Always verify that your profile time zone is set correctly in every tool you use. A laptop that has traveled from New York to London but still shows EST in its system clock will feed incorrect data to every scheduling app.
Common DST Mistakes with Real Examples
Mistake 1: "The Meeting Moved Itself"
What happened: A team had a recurring Thursday call at 9:00 AM ET / 2:00 PM London. The US sprang forward on Sunday. On Thursday, the London team joined at 2:00 PM—but the meeting was now at 1:00 PM London time. They missed the call.
Why: The London participants had saved "2:00 PM" in their personal notes and did not realize the calendar had adjusted. They were relying on memory rather than the calendar invite.
Fix: Never save meeting times in a different time zone without the UTC reference. Trust your calendar app, not your notes.
Mistake 2: "We Double-Booked"
What happened: After the EU fell back, a project manager in Berlin scheduled a new meeting for 3:00 PM CET. She checked the New York team's calendar and saw a free slot at 9:00 AM ET. But she was looking at the old (summer) offset. With the winter offset, 3:00 PM CET was actually 9:00 AM EST—and that slot was already taken. The double-booking was not caught until both meetings tried to start simultaneously.
Why: She manually converted the time using the summer offset (6 hours) instead of the winter offset (5 hours).
Fix: Use a scheduling tool that auto-converts, or always check the current UTC offset before manually converting.
Mistake 3: "The India Team Was an Hour Late"
What happened: A US–India standup was set for 8:00 AM EST / 6:30 PM IST. The US sprang forward on March 8. On March 10, the India team joined at 6:30 PM IST—but the meeting had already happened at 5:30 PM IST (because EST became EDT, and the gap shrunk by one hour).
Why: The India team's calendar was not syncing with the US organizer's calendar correctly. The meeting invite stored the time in EST rather than UTC, and the India calendar did not account for the change.
Fix: Re-create the meeting with the time stored in UTC. Verify that all participants' calendars display the correct local time.
Mistake 4: "We Scheduled a Webinar During the Mismatch"
What happened: A SaaS company scheduled a global product launch webinar for March 20. The invite said "10:00 AM PT / 1:00 PM ET / 5:00 PM London." But on March 20, the US was on PDT while London was still on GMT. The correct London time was 4:00 PM, not 5:00 PM. London attendees arrived an hour late.
Why: The organizer used the winter offset (8 hours between PT and London) without accounting for the US spring forward.
Fix: Always verify time differences within 2 weeks of any DST transition. Use a tool like World Time Buddy that accounts for current DST status.
Checklist: DST-Proof Your Meeting Schedule
- Have I identified which participants are in DST-observing regions and which are not?
- Are all recurring meetings stored in UTC in my calendar platform?
- Do I include UTC offsets in all meeting invitations and email confirmations?
- Have I scheduled a DST audit for the week before the next transition?
- Do I have the 2026 danger weeks marked on my team calendar?
- Have I sent a reminder to all participants at the start of each danger week?
- Is my laptop/phone system clock set to the correct time zone for my current location?
- Have I verified that my scheduling tool (Calendly, etc.) displays the correct times after a DST transition?
- Am I using a calendar app that auto-adjusts for DST, rather than relying on manual time conversion?
- Have I added a 15-minute buffer to meetings on DST transition days?
- Do I rotate who accommodates when the offset changes, rather than always burdening the same team?
FAQ
What is daylight saving time (DST)?
Daylight saving time is the practice of moving clocks forward by one hour in spring and back by one hour in fall. The goal is to extend daylight into the evening hours. Approximately 70 countries observe DST, but the dates of the change vary by country, and many countries do not observe it at all.
Why does DST cause meeting scheduling errors?
DST causes errors because different countries change clocks on different dates. During the gap between one country's transition and another's, the time difference between them is temporarily off by one hour. Teams that rely on a fixed time difference for their recurring meetings discover that the meeting has shifted in one participant's local time.
When do the US and EU change clocks in 2026?
The US springs forward on March 8, 2026 and falls back on November 1, 2026. The EU springs forward on March 29, 2026 and falls back on October 25, 2026. The 21-day gap in March and the 7-day gap in October/November are the "danger weeks" when time differences are temporarily off.
Which major countries do not observe DST?
China, India, Japan, Singapore, South Korea, Saudi Arabia, and the UAE do not observe DST. This means the time difference between these countries and DST-observing countries (like the US and UK) changes twice a year.
How do I make my recurring meetings DST-proof?
Store all recurring meetings in UTC rather than in a local time zone. Most modern calendar apps do this by default. Verify by checking the meeting time in a participant's time zone before and after a DST transition—it should stay the same in their local display if the meeting is correctly stored in UTC.
What should I do during the "danger weeks" when time differences are off?
Send a reminder to all participants with the meeting time listed in every relevant time zone. Double-check your calendar for correct display. Start meetings with a quick time check. Be patient with participants who join at the wrong time—it is the schedule's fault, not theirs.
Does Arizona observe DST?
Most of Arizona does not observe DST. The state stays on Mountain Standard Time (MST, UTC-7) year-round. (The Navajo Nation in northeastern Arizona does observe DST.) This means during summer, Arizona aligns with Pacific Daylight Time (PDT, also UTC-7), and during winter, Arizona is one hour ahead of Pacific Standard Time (PST, UTC-8). Always verify the time for Arizona-based participants.
Is the EU going to abolish DST?
The European Parliament voted in 2019 to abolish seasonal clock changes, but implementation has been repeatedly delayed. As of 2026, EU member states still observe DST. If the EU does eventually abolish DST, it would create a permanent mismatch with the US for parts of the year. Monitor EU policy updates if your team spans both regions.
Put this into action
Stop guessing. Use our professional tools to schedule, convert, and manage time zones perfectly — 100% free.
Plan Your MeetingOfficial Sources & References
- IANA Time Zone Database — The global standard database for time zone boundaries and daylight saving shifts.
- National Institute of Standards and Technology (NIST) — Official U.S. timekeeping and standards definitions.


