March Daylight Saving Time Meetings: Shift vs Anchor UTC

It's the Second Monday of March. Your 9 AM Standup Has Three People in It.

Half your team is already deep into their second coffee. The other half is staring at an empty video call, wondering if they somehow missed an email. Nobody did anything wrong — except that nobody remembered the clocks moved forward at 2 AM on Sunday, and your calendar app quietly shifted the meeting for some attendees while leaving others exactly where they were.

If you coordinate a distributed team that spans, say, New York, London, and Bangalore, you already know this scenario. You've probably lived through it. And if you haven't fixed your recurring meeting setup since the last time change in November, you're about to live through it again when daylight saving time begins in March.

Let's walk through what actually breaks, why it breaks, and how to adjust recurring meeting times so your team stops losing the first 48 hours of every spring to scheduling confusion.

The Problem: Why Recurring Meetings Collapse Twice a Year

Most remote teams set up recurring meetings using their calendar app's default behavior. You pick a time — say, 9:00 AM Eastern — and invite attendees across four or five time zones. The calendar converts each attendee's local time based on the current offset, and everyone gets a neat little notification telling them when to show up.

Here's where it falls apart.

Not Every Time Zone Observes Daylight Saving Time

When DST begins in March, the Eastern time zone shifts from UTC-5 to UTC-4. But Phoenix doesn't shift. It stays at UTC-7 year-round. Tokyo doesn't observe DST at all — it's always UTC+9. And while most of Europe does observe DST, it doesn't switch on the same date as North America. The EU typically changes clocks on the last Sunday of March, roughly two to three weeks after the US and Canada.

So for that gap between the US switch and the EU switch, your 9:00 AM Eastern meeting is suddenly at a different local time in London than it was the previous week. A meeting that was 2:00 PM in London is now 1:00 PM. Your London colleagues who blocked 2:00 to 3:00 PM on their calendar for the last four months now have a conflict they didn't create.

Calendar Apps Handle This Differently — and That's the Real Trap

Google Calendar, Outlook, and Zoom all store recurring meeting times differently under the hood. Some anchor the meeting to a specific UTC offset and recalculate when offsets change. Others anchor to the organizer's local time, which means the UTC time itself shifts when the organizer's clock moves forward.

This is why you'll sometimes see the same meeting show up at two different times on two different platforms. Your calendar says 9:00 AM. Your Zoom link says 10:00 AM. Your Slack reminder fired at 8:30 AM. And your colleague in Mumbai, who doesn't observe DST, is now joining an hour early because India's offset relative to Eastern time just changed by 60 minutes.

The Cause: You're Thinking in Local Time Instead of UTC

The root cause of almost every DST meeting failure is simple: the person who set up the recurring meeting thought in local time.

When you schedule a recurring meeting for "9:00 AM my time," you're telling the calendar: "Make this 9:00 AM in my time zone, every week, forever." That works fine until your time zone changes its offset. Then the calendar does one of two things — it either keeps 9:00 AM local for you (which shifts the UTC time and moves the meeting for everyone else), or it keeps the original UTC time (which shifts your local time).

Neither behavior is wrong. But if you don't know which one your platform uses, you can't predict what will happen on March 10th.

Here's a concrete example. Let's say your team stands up at 9:00 AM Eastern (UTC-5) every Monday. That's 14:00 UTC. For your developer in Berlin (UTC+1 in winter), that's 3:00 PM local. For your designer in Mumbai (UTC+5:30), that's 7:30 PM local.

When Eastern shifts to UTC-4 on March 10th:

• If your calendar keeps the meeting at 9:00 AM Eastern, the UTC time moves to 13:00 UTC. Berlin is now at 2:00 PM (one hour earlier). Mumbai is now at 6:30 PM (one hour earlier).
• If your calendar keeps the meeting at 14:00 UTC, Eastern becomes 10:00 AM. Berlin stays at 3:00 PM. Mumbai stays at 7:30 PM.

Same meeting. Completely different outcomes depending on how the platform stores it. And if you're using a time zone converter to double-check, you need to make sure you're converting for the post-DST date, not today's date — because the offsets won't be the same.

The Fix: A Step-by-Step Process for Adjusting Recurring Meetings Before DST Hits

Here's how to handle this properly, whether you're managing a five-person team or coordinating across fifteen time zones.

Step 1: Identify Which Meetings Are Anchored to a DST-Observing Time Zone

Pull up every recurring meeting on your calendar. For each one, note the organizer's time zone. If the organizer is in a DST-observing zone (most of the US, Canada, EU, parts of Australia), that meeting will shift on March 10th (US) or March 31st (EU) — unless you intervene.

Meetings organized by someone in a non-observing zone (Arizona, Hawaii, most of Asia, parts of South America) won't shift on their end, but the local times for DST-observing attendees will still change.

Step 2: Convert the Current Meeting Time to UTC

Use a reliable time zone converter to calculate the current UTC time of your meeting. This is your anchor. Write it down. For our example, 9:00 AM Eastern Standard Time = 14:00 UTC.

This UTC time is the one thing that should stay constant if you want everyone's local schedule to remain unchanged after DST.

Step 3: Decide Whether You Want to Preserve UTC or Preserve Local Time

This is a decision, not an accident. You have two options:

Option A: Preserve UTC. Keep the meeting at 14:00 UTC year-round. This means DST-observing attendees will see their local time shift by one hour twice a year, but non-observing attendees keep a stable local time. This is usually the better choice if most of your team is outside the US or EU.

Option B: Preserve the organizer's local time. Keep the meeting at 9:00 AM Eastern year-round. The UTC time shifts, and every non-observing attendee's local time shifts by one hour. This is better if most of your team is in the same DST-observing zone as the organizer.

The mistake most people make is not making this decision at all — they let the calendar default decide, and then they're surprised by the outcome.

Step 4: Update the Recurring Meeting Before the Switch Date

Don't wait until March 10th to fix this. The Friday before, go into your calendar and edit the recurring series. Most platforms — Google Calendar, Outlook, Zoom — will ask whether you want to update just one instance or the entire series. Choose the entire series.

If you're preserving UTC (Option A), set the meeting time to the new local time that corresponds to 14:00 UTC after the DST switch. For Eastern Daylight Time (UTC-4), that's 10:00 AM. Update the series to 10:00 AM Eastern.

If you're preserving local time (Option B), you don't need to change anything — but you do need to notify non-observing attendees that their local meeting time has shifted. Send a message to your team in Mumbai, Phoenix, or Tokyo explaining that the meeting is now one hour earlier (or later) in their local time until the next DST change.

Step 5: Verify With a Time Zone Converter Using the Post-DST Date

This is the step most people skip, and it's where the hidden mistakes live. After you've updated the meeting, open a time zone converter and set the date to March 17th — a week after the US DST switch, but before the EU switch. Check the local time for each attendee.

If your Berlin attendee shows 3:00 PM on March 17th but showed 2:00 PM on March 3rd, you've confirmed the EU gap. Their time will shift back to 3:00 PM on March 31st when the EU switches. You need to tell them this, or they'll think the calendar is broken.

Run the same check for every time zone on your team. Note any that change between March 10th and March 31st. Those attendees are in the "gap window" and need a heads-up.

Step 6: Send a One-Line Notification to the Team

Don't write a novel. Don't explain UTC offsets. Just tell people what they need to know:

"Heads up: our Monday standup stays at 9:00 AM ET for everyone in North America. For teammates in Europe, the meeting moves to 2:00 PM local from March 10th through March 31st, then returns to 3:00 PM. For teammates in India, the meeting is now at 6:30 PM IST until the next time change in November."

That's it. Clear, specific, actionable. No confusion about whose clock moved or why.

Common Pitfalls to Watch For

Even with a solid process, a few traps catch teams every March.

The Zoom link time mismatch. Zoom stores meeting times in the organizer's time zone, but if you created the meeting through Google Calendar, the two platforms may interpret the DST shift differently. After updating the calendar event, open the Zoom meeting settings and verify the time matches. If it doesn't, regenerate the Zoom link from the updated calendar event.

The forgotten Arizona exception. If you have teammates in Arizona, remember: they don't observe DST. When the rest of Mountain Time shifts from UTC-7 to UTC-6, Arizona stays at UTC-7. Your Arizona colleagues' meeting time relative to Eastern will shift by an hour unless you've preserved UTC. A time zone converter set to March 17th will catch this.

The "I'll just check my phone" assumption. Phone clocks update automatically for DST, but calendar apps don't always sync the same way — especially if you're using a third-party scheduling tool or a legacy Outlook setup. Verify meeting times on the actual platform where the meeting lives, not just on your phone's clock app.

Build a Reminder for Next Time

The teams that handle DST smoothly aren't the ones with the fanciest scheduling tools. They're the ones who remember it's coming. Set a calendar reminder for the first Friday of March and the first Friday of November. That gives you a 48-hour window to audit your recurring meetings, convert times to UTC, make your preserve-or-shift decision, and notify the team before the clocks move.

It takes about 20 minutes if you do it proactively. It takes two days of confusion, three missed meetings, and one frustrated Slack thread if you don't. Use a time zone converter, anchor to UTC, and make the decision deliberately. Your team will thank you — or more accurately, they won't say anything at all, which is the best possible outcome when it comes to scheduling.