3 Cross-Time Zone Meeting Mistakes During Daylight Saving

The "Set It and Forget It" Calendar Trap

You probably set up your global team’s weekly sync back in November. You picked 9:00 AM your time in New York, added your developers in London and your QA engineers in Bangalore, hit "repeat weekly forever," and breathed a sigh of relief. For five months, it worked beautifully. Then March rolled around, and suddenly your London team is logging in an hour late, and your Bangalore team is furious because the meeting has silently shifted from 7:30 PM to 8:30 PM their time.

This is the single most common pain point for anyone managing global teams: the blind belief that calendar software’s "recurring meeting" feature handles cross-time zone daylight saving time (DST) transitions automatically. It doesn't. Well, it does—sort of—but it does so based on the meeting creator's local DST rules, completely ignoring how those rules interact with the rest of the world.

If you are coordinating a distributed workforce, treating time zones as static labels is a recipe for disaster. As someone who lives in the world of time zone conversion, I see project coordinators make the same handful of scheduling mistakes every spring and autumn. Let's break down exactly why your recurring meetings break during DST shifts, and the step-by-step fixes to keep your global team in sync.

Mistake 1: Trusting "Local Time" Recurrence Across Borders

Why 9:00 AM Isn't Always 9:00 AM

The biggest misconception is that a recurring meeting set for 9:00 AM EST will remain 9:00 AM EST forever. When you create a recurring meeting in Outlook or Google Calendar, the system anchors that meeting to your specific local time zone and its DST observance.

Here is what happens under the hood: When the US "springs forward" in March, your 9:00 AM meeting remains 9:00 AM your time. But because the US shifted its clocks while the rest of the world stayed put, the underlying UTC offset changed. Your 9:00 AM EST (UTC-5) suddenly became 9:00 AM EDT (UTC-4). If your London colleague’s calendar is set to GMT/BST, they were previously joining at 2:00 PM. After your US shift, the meeting on their calendar automatically updates to 1:00 PM. You didn't change the meeting; the shifting offset changed it for them.

The Fix: Stop relying on your local time as the anchor for global meetings. If you have a truly global team, you need to shift your mindset from "local time" to "UTC time."

Mistake 2: Ignoring the Three-Week "DST Danger Zone"

The US vs. Europe Time Warp

Let’s look at a concrete, real-world calculation that trips up even seasoned project managers. The United States transitions to Daylight Saving Time on the second Sunday of March. Europe doesn't transition until the last Sunday of March.

For those three weeks in March, the time difference between New York and London shrinks from five hours to four hours. If you usually hold a meeting at 10:00 AM in New York (3:00 PM in London), it will suddenly become 10:00 AM EDT (2:00 PM GMT) for your UK team during those three weeks. If you didn't account for this, your UK team will either join an hour early or miss the meeting entirely, assuming the original 3:00 PM slot still holds.

The Fix: You must map out the "DST Danger Zone." Instead of guessing, pull up a reliable time zone converter and plot the exact transition dates for every region your team inhabits. Note the US transition (March 10, 2024, for example) and the EU transition (March 31, 2024). You need to treat those three weeks as a distinct scheduling phase. Send a calendar update specifically for that interim period, manually adjusting the time so the UTC offset remains constant for everyone involved.

Mistake 3: Forgetting the "Non-DST" Outliers

The Asia-Pacific Blindspot

While North America and Europe are busy shifting their clocks, large portions of the world—including India, China, Japan, and Singapore—do not observe DST at all. Project managers often assume that if a meeting time works in January, it will work in July. But for teams bridging the US and Asia, the DST shift completely alters the workday overlap.

Consider a team in New York and a team in Bangalore. In January, a 9:00 AM EST call happens at 7:30 PM IST. It's late for Bangalore, but manageable. When New York springs forward to EDT in March, 9:00 AM EDT suddenly becomes 6:30 PM IST. While a one-hour shift might not seem catastrophic on paper, if your Bangalore team relies on a strict evening commute or childcare schedule, that 6:30 PM slot might suddenly overlap with personal obligations that the 7:30 PM slot did not.

The Fix: Identify your non-DST observing team members and calculate their shifting burden. When you use a time zone converter, look at the UTC offset of your non-DST locations. Because their offset doesn't change, the burden of the shift falls entirely on them. To fix this, consider implementing a rotating meeting time for the summer months. If Bangalore takes the hit in March, perhaps New York takes an earlier or later hit in autumn to balance the inconvenience.

The Ultimate Step-by-Step Workflow for DST-Proof Meetings

Now that we've dismantled the bad practices, here is the exact workflow you should use to schedule recurring cross-time zone meetings that survive daylight saving time transitions.

Step 1: Anchor the Meeting to a Fixed UTC Time

Forget local wall-clock times. Decide on a fixed UTC time for your meeting. For example, let's say your global standup needs to happen at 14:00 UTC. This is your immovable anchor. No matter what the clocks do in New York, London, or Tokyo, 14:00 UTC is always 14:00 UTC.

Step 2: Translate the UTC Time for Each Region

Next, use a time zone converter to translate 14:00 UTC into the local times for your team members. Do this for both the winter (standard) and summer (daylight) periods.

• Winter (EST): 14:00 UTC = 9:00 AM in New York
• Summer (EDT): 14:00 UTC = 10:00 AM in New York

By understanding this translation, you realize that if you want to keep the meeting at 9:00 AM for New York year-round, you are actually changing the UTC anchor from 14:00 UTC in the winter to 13:00 UTC in the summer. Changing the anchor is what causes chaos for your international teams. Keep the UTC anchor fixed.

Step 3: Set Custom Calendar Recurrence

Do not hit "weekly forever." Instead, set up two separate recurring meeting series in your calendar.

1. Series A (Standard Time): Set this to run from November to March. Use the winter UTC offset translations for the meeting title (e.g., "Global Sync - 9 AM NY / 2 PM London / 7:30 PM Bangalore").
2. Series B (Daylight Time): Set this to run from March to November. Update the local times in the title to reflect the DST shift (e.g., "Global Sync - 10 AM NY / 3 PM London / 7:30 PM Bangalore").

what times the meeting should occur in each phase, eliminating the guesswork that leads to missed calls and frustrated teammates.

Step 4: Audit Your Calendar Software's DST Behavior

Not all calendar applications handle DST the same way, and assuming they do is a mistake that can silently break your schedule. Google Calendar, Microsoft Outlook, and Apple Calendar each have their own internal logic for how they process recurring meetings across time zone boundaries. Before you send out your carefully planned series, do a manual audit.

Create a test meeting and invite yourself. Then, scroll forward in your calendar to the weeks surrounding the DST transition dates. Check whether the meeting time shifts for your invitees in different time zones. If you see unexpected jumps, you know your calendar software is applying its own DST logic on top of your settings, and you need to adjust accordingly. This five-minute check can save you from weeks of confusion.

Step 5: Communicate Proactively Before Every Transition

Even the most perfectly structured calendar invite can't replace clear human communication. Send a brief reminder to your team at least one week before any DST transition. Include the specific date the change occurs, the new local meeting time for each region, and a link to a time zone converter so team members can verify their own local time.

A simple message like this goes a long way: "Heads up, the US shifts to Daylight Saving Time on March 10. Our Tuesday standup will move from 9:00 AM to 10:00 AM for the New York team. London, you will now join at 3:00 PM instead of 2:00 PM. Bangalore, your time stays at 7:30 PM IST." Clarity eliminates the anxiety of wondering whether a meeting has moved or not.

Common DST Scheduling Questions to Anticipate

As you implement this workflow, expect pushback from team members who have never thought about time zones in terms of UTC offsets. The most common question is, "Why can't we just pick a time that works for everyone and keep it there?" The answer is simple: because the Earth's rotation doesn't change, but our clocks do. If you anchor to a local time, you are implicitly changing the UTC offset twice a year, which means someone else's local time is shifting whether they like it or not.

Another frequent concern is whether splitting meetings into two calendar series creates confusion. In practice, the opposite happens. When team members see a meeting title that explicitly lists their local time, they feel confident about when to join. The confusion comes from a single recurring meeting that silently shifts on their calendar without explanation.

Tools That Make DST Management Easier

Beyond your standard calendar application, a dedicated time zone converter is your best friend during DST transitions. Use it to verify offsets for every team member's location, not just the major hubs. If you have a contractor in Arizona, which does not observe DST despite being in the US, your converter will flag that discrepancy. If you have a team member in Adelaide, Australia, where DST transitions on different dates than the Northern Hemisphere, your converter will catch that too.

Some teams also benefit from world clock widgets or dashboard tools that display multiple time zones simultaneously. These visual aids help team members develop an intuitive sense of the overlap windows, rather than relying on mental math every time they schedule a call.

The Bottom Line

Daylight Saving Time doesn't have to be a scheduling nightmare. The mistakes that break cross-time zone meetings, trusting local time recurrence, ignoring the US-EU gap, and forgetting non-DST regions, all stem from one root cause: treating time zones as fixed labels rather than shifting UTC offsets. By anchoring your meetings to a fixed UTC time, splitting your calendar series into standard and daylight periods, auditing your software, and communicating proactively, you can create a scheduling system that survives every spring forward and fall back. Your global team already deals with enough complexity navigating different languages, cultures, and work norms. Don't make them guess when the next meeting starts too.