Daylight Saving Shifts: Fix Recurring Meetings in 5 Minutes

That Monday When Half My Team Vanished

It was the second Monday of March. I logged into our daily standup at 9:30 AM Eastern, coffee in hand, ready to review sprint progress with my team spread across Boston, London, and Bangalore. The Boston folks were there. London? Silent. Bangalore? Crickets. I sat alone on a video call for seven minutes before Slack lit up with messages: "Did the meeting time change?" "I thought it was at 2:30 PM my time." "Wait, is it today or tomorrow for me?"

Nobody had changed the meeting time. But daylight saving time had kicked in over the weekend in the United States, while the UK and India hadn't moved yet. The one-hour shift quietly broke a recurring meeting that had been running smoothly for months. If you've ever managed a global team, you've probably lived through some version of this exact scenario. And if you haven't yet, you will.

Why This Keeps Happening to Good Teams

The core problem isn't that people forget about daylight saving time. It's that calendar apps treat recurring meetings as fixed to a single time zone, while DST changes operate like invisible hands nudging certain zones forward or backward by an hour. When only some regions shift and others don't, the overlap window you carefully engineered collapses.

Here's the specific math from my situation. Our standup was set for 9:30 AM Eastern / 2:30 PM London / 7:00 PM Bangalore. When US Eastern moved from UTC-5 to UTC-4 on March 12, but London remained at UTC+0 until March 26, the gap between Eastern and London temporarily shrank from five hours to four. My 9:30 AM Eastern meeting was now 1:30 PM in London, not 2:30 PM. And Bangalore, which doesn't observe DST at all, suddenly saw the meeting jump from 7:00 PM to 8:00 PM. People were showing up an hour late or an hour early depending on where they sat.

The lesson hit hard: recurring meetings across time zones are not "set it and forget it." They require active maintenance around DST transitions, which happen on different dates in different regions.

Step 1: Map Every Team Member's Time Zone and DST Schedule

Before you can fix anything, you need a clear picture of who is where and when their clocks change. This sounds obvious, but most teams skip it because they assume their calendar handles it automatically. It doesn't, at least not in a way that communicates clearly to humans.

Start by listing every participant in your recurring meeting alongside their city, current UTC offset, and the date their region next observes a DST change. You can pull this information quickly using a reliable time zone converter that displays offset details alongside the conversion. The goal is to build a simple reference table you can revisit twice a year.

Building Your Reference Table

For my team of twelve, the table looked like this. Boston: UTC-5 (EST), shifts to UTC-4 (EDT) on March 12. London: UTC+0 (GMT), shifts to UTC+1 (BST) on March 26. Bangalore: UTC+5:30 (IST), no DST shift ever. Sydney: UTC+11 (AEDT), shifts to UTC+10 (AEST) on April 2.

That table told me everything I needed to know. Between March 12 and March 26, the US and UK were temporarily out of their normal alignment by one hour. Between March 26 and April 2, the US and UK were aligned again, but Sydney had shifted, creating a new misalignment with Australia. The "danger zone" wasn't a single day. It was a multi-week window where offsets were in flux.

Step 2: Identify the Overlap Windows Before and After Each DST Shift

Once you have your table, the next step is to calculate your meeting time across all participant zones for three scenarios: before any DST change, during the transitional mismatch period, and after all regions have settled into their new offsets.

This is where a world clock tool or a multi-city time zone converter becomes invaluable. Plug in your meeting time for each scenario and see where the landmines are.

For our standup, the analysis revealed the following. Before March 12, 9:30 AM Eastern worked for everyone. During the March 12 to March 26 window, 9:30 AM Eastern became 1:30 PM London, which was still acceptable, but it became 8:00 PM Bangalore, which pushed into personal time. After March 26, when London also shifted, 9:30 AM Eastern returned to 2:30 PM London but stayed at 8:00 PM Bangalore because India never moves.

The real problem wasn't London. It was Bangalore getting stuck with an 8:00 PM meeting for two weeks, and then permanently if we didn't adjust.

Step 3: Decide Whether to Hold, Shift, or Split During the Transition

You have three options when a DST change disrupts your recurring meeting, and each comes with tradeoffs.

Option one is to hold the meeting at the same UTC time throughout the transition. This means participants in shifting regions experience a one-hour change in their local meeting time, but non-shifting regions stay put. For our team, holding at UTC 2:30 meant Boston moved from 9:30 AM to 10:30 AM temporarily, London stayed at 2:30 PM, and Bangalore stayed at 7:00 PM. This protected Bangalore but asked Boston to adjust.

Option two is to hold the meeting at the same local time for the meeting organizer's zone. This is what calendar apps do by default, and it's what caused my original problem. The organizer's local time stays constant, but everyone else's shifts.

Option three is to split the meeting into two recurring blocks, one for the pre-DST period and one for the post-DST period, with adjusted times that work for everyone in each window. This requires more setup but gives you the cleanest outcome.

I chose option one for the two-week transitional gap, then switched to a new permanent time after all regions had settled. Holding at a fixed UTC time during transitions is the approach I now recommend to anyone managing scheduling meetings across time zones on a recurring basis.

Step 4: Communicate the Change Before It Happens, Not After

The biggest mistake I made in my March disaster was not warning anyone. The calendar updated silently, and people assumed the time they saw was correct. Some were wrong.

Send a message to all meeting participants at least one week before a known DST transition. State the current meeting time in each person's local zone, the new meeting time during the transition, and the final meeting time after all regions have shifted. Be explicit. "Starting Monday, March 13, our standup moves from 2:30 PM to 1:30 PM London time for two weeks, then returns to 2:30 PM on March 27."

Use your time zone converter to generate each person's specific local time so nobody has to do math themselves. People appreciate when you hand them the answer rather than asking them to calculate it.

Step 5: Set Calendar Reminders for the Next DST Transition

DST changes happen roughly twice a year, but the dates vary by country. The US shifts in March and November. Europe shifts in March and October. Australia shifts in April and October. Many countries don't shift at all.

Set a recurring reminder for yourself at least two weeks before each major transition period. When the reminder fires, pull up your reference table, run your meeting time through a time zone calculator for the new offsets, and send out the update. This turns a recurring crisis into a routine maintenance task that takes fifteen minutes.

I now have four reminders per year: early March, late March, early October, and early November. Each one triggers the same checklist. Check offsets, run conversions, communicate changes, update calendar invites if needed.

Step 6: Document the Final Schedule in a Shared, Time-Zone-Aware Format

After you've navigated a DST transition, capture the outcome somewhere your whole team can reference. A shared document or wiki page with the meeting time listed in UTC plus each participant's local zone eliminates ambiguity. Include a note about the next upcoming DST change and what to expect.

The format I use is simple. Meeting name, UTC time, local times for each city, next DST review date. When a new person joins the team, they read this page and immediately understand when the meeting happens and why the times might shift twice a year. It also gives me a single source of truth to verify against my international meeting planner tool whenever something feels off.

The Real Takeaway

Daylight saving time isn't a one-day event for global teams. It's a multi-week window of misaligned offsets that can silently break your recurring meetings if you're not paying attention. The fix isn't complicated, but it requires intentionality. Map your team's zones, calculate the transitional overlaps, decide how to handle the gap, communicate clearly, set reminders, and document the result.

My March standout disaster taught me that calendar apps are tools, not strategists. They'll display a time, but they won't tell you whether that time still works for the human beings on the other end. That part is on you. And now, hopefully, you have a process for it.