How to Schedule Recurring Global Standups Across 5 Time Zones During Daylight Saving Time Transitions

How do you keep a 5-time-zone standup from imploding when daylight saving time hits?

You set up a clean recurring meeting. It works for three months. Then October or March rolls around, and suddenly your developer in Berlin is showing up at 4:30 PM instead of 3:30 PM, your teammate in Sydney is either an hour early or an hour late depending on which side of the equator you're thinking about, and someone in Bangalore is confused because their clock didn't change at all.

I've watched this exact scenario play out on distributed engineering teams more times than I can count. The standup dies not because the concept is flawed, but because nobody mapped the daylight saving time transitions before hitting "make recurring." Let's fix that. Below is a checklist-driven walkthrough of every sub-question you need to answer to keep your global standup alive through DST chaos.

Why does daylight saving time wreck recurring meetings?

Because calendar apps are quietly doing one of two things, and neither is great:

Option A: The meeting stays pinned to UTC

This means the meeting time is stable in UTC, but everyone's local time shifts by an hour when their region enters or exits DST. Your 9:00 AM standup in New York suddenly becomes 10:00 AM. Or 8:00 AM. Depending on direction.

Option B: The meeting stays pinned to the organizer's local time

This means the organizer's clock stays stable, but everyone else's local meeting time shifts relative to the organizer when their own DST changes hit.

Neither option is inherently wrong. The disaster happens when you don't know which one your calendar is using and you haven't communicated it to the team. A developer in Bangalore (which observes no DST) might assume the meeting moved. A developer in Berlin might assume it didn't. Now you have three people in the standup and two people wondering where everyone is.

Which time zones spring forward and which hold steady?

Before you can schedule anything, you need a map of who changes and when. Here's the cheat sheet for the five time zones most global teams juggle:

New York (Eastern Time): DST runs from the second Sunday in March to the first Sunday in November. UTC offset shifts from -5 to -4.

London (GMT/BST): DST runs from the last Sunday in March to the last Sunday in October. UTC offset shifts from +0 to +1.

Berlin (CET/CEST): Same dates as London. UTC offset shifts from +1 to +2.

Bangalore (IST): No DST. UTC offset stays at +5:30. Forever. Blessed.

Sydney (AEST/AEDT): DST runs from the first Sunday in October to the first Sunday in April. Yes, it's flipped because Southern Hemisphere. UTC offset shifts from +10 to +11.

The critical insight: there are roughly three weeks per year

forward but London and Berlin haven't yet, or vice versa. These gap weeks are where standups go to die. During those windows, the offset between New York and Berlin temporarily shrinks from six hours to five, or the offset between Sydney and Bangalore shifts in a direction nobody expected. If your recurring meeting was set up with a fixed local time in one zone, the math breaks for everyone else during these transition windows — and nobody realizes it until half the team misses the call.

How do you map every DST transition before scheduling?

You don't need to memorize the rules. You need a single reference table that covers the next 12 months of transitions for all five zones. Build it once, revisit it twice a year, and you'll never get caught off guard. Here's what that mapping process looks like:

• Step 1: List the exact transition dates for each time zone for the current year. Don't approximate. "Second Sunday in March" is not the same date every year — look it up.
• Step 2: Identify the gap weeks — the periods between when one zone changes and the next zone changes. These are your danger zones.
• Step 3: Calculate the UTC offset for each zone during each gap period so you know exactly who's shifted and who hasn't.
• Step 4: Pick a single anchor time in UTC that works for all five zones across all six periods (pre-DST, gap weeks, post-DST, and the reverse in autumn).

If that sounds tedious, it's because it is — the first time. After that, you update two dates per year and you're done. A reliable time zone converter tool handles the offset math for you; your job is just to know when the transitions happen and plan around them.

Should you pin the standup to UTC or to the organizer's local time?

This is the single most important decision, and most teams make it by accident. Here's how to choose deliberately:

Pin to UTC when:

• Your team is truly distributed across multiple regions with no clear majority in one zone.
• You want fairness — everyone takes a roughly equal share of inconvenience.
• Your team is comfortable thinking in UTC (common in engineering and DevOps cultures).
• You're using a tool like a time zone converter to verify offsets weekly.

When you pin to UTC, the standup time is stable in UTC but shifts by one hour in local time for anyone observing DST. That means twice a year, four of your five time zones will see the local meeting time change. Bangalore won't. The advantage: the meeting never drifts relative to global time, so it's predictable once everyone understands the pattern. The disadvantage: you have to communicate the local-time shift every transition, or people will show up at the wrong hour.

Pin to the organizer's local time when:

• One time zone has the majority of team members.
• The organizer is the key decision-maker and their availability is non-negotiable.
• Your team struggles with UTC and prefers thinking in local time.

When you pin to the organizer's local time, the organizer never has to think about DST — their standup stays at 9:00 AM year-round. But everyone else's local time shifts twice a year, and the shift direction depends on whether their DST moves in the same direction as the organizer's. If the organizer is in New York and a teammate is in Sydney, their DST transitions happen in opposite directions and at different times of year, which means the Sydney teammate's local standup time could shift by two hours in a single month.

My recommendation for a five-zone team: pin to UTC. It's the only option that doesn't silently favor one region, and it forces the kind of explicit communication that prevents confusion.

How do you set up the recurring meeting so it survives DST?

Most calendar apps — Google Calendar, Outlook, Zoom — give you options for how recurring meetings handle time zone changes. Here's the practical setup:

• In Google Calendar: When creating the recurring meeting, set the time zone explicitly to UTC rather than your local time zone. This pins the meeting to UTC and ensures it stays stable regardless of who changes their clocks. Use the "Time zone" dropdown next to the time field, not your account default.
• In Outlook: Outlook handles recurring meetings differently depending on whether you're using the desktop app or web version. In the desktop app, recurring meetings are pinned to the organizer's local time zone by default. To pin to UTC, you'll need to set the meeting time zone to UTC when creating the event and make sure attendees are invited with the UTC reference.
• In Zoom: If you're scheduling through Zoom directly, set the meeting to "Recurring meeting" and choose "Fixed time" rather than "No fixed time." Then set the time zone to UTC. Zoom will respect the UTC pin across DST transitions for attendees.

Whatever tool you use, the key is to verify the meeting's behavior before the next DST transition. Create a test event, fast-forward your calendar view to the week after the transition, and check what local time the meeting shows for each region. If it's wrong, you've got time to fix it.

How do you communicate DST changes without causing chaos?

Even with perfect scheduling, people forget. Here's a communication cadence that works:

• Two weeks before a transition: Post a reminder in your team channel with the exact date of the change and the new local meeting time for each affected zone. Use a table format so people can scan for their city.
• One week before: Send a calendar invite update — even if the meeting time in UTC hasn't changed, sending an updated invite forces the event to refresh in everyone's calendar and reduces the chance of stale cached times.
• Day of the transition: A quick ping in the standup channel: "Reminder: DST changes today for [regions]. Standup is still at [UTC time], which is now [new local time] for [affected zones]."
• One week after: Check in. Ask if the new local times are still workable. If someone is now stuck with a 7:00 AM or 7:00 PM standup, it's time to renegotiate the anchor UTC time.

The goal isn't to over-communicate — it's to make the invisible visible. DST transitions are silent. Nobody's calendar sends a push notification saying "by the way, your meeting just shifted." You have to be that notification.

What's the pre-DST checklist for a 5-zone standup?

Here's the condensed checklist to run through before every DST transition — twice a year, every year:

• Identify which of your five time zones are transitioning and on what exact dates.
• Map the gap weeks between transitions and flag them as high-risk for missed standups.
• Verify your calendar tool is pinning the meeting to UTC (or your chosen anchor), not silently defaulting to the organizer's local time.
• Calculate the new local meeting time for each time zone post-transition using a time zone converter.
• Confirm no one's new local time falls outside reasonable working hours (before 8:00 AM or after 7:00 PM local).
• Send the two-week reminder with the updated local times for each region.
• Send a calendar invite refresh one week before the transition.
• Post a day-of reminder in the standup channel.
• Do a post-transition check one week later to catch anyone who's silently struggling.

The Bottom Line

DST doesn't wreck global standups because the time changes are unpredictable — they're entirely predictable, down to the exact Sunday. Standups die because teams treat the recurring meeting as "set it and forget it" and then act surprised when October or March reshuffles everyone's local time. The fix isn't complicated: pin to UTC, map the transition dates, communicate before each change, and run the checklist twice a year. A five-zone standup will never be effortless, but it can be reliable. The teams that keep theirs alive aren't the ones with the fanciest scheduling tools — they're the ones who know that "recurring" doesn't mean "maintenance-free."