Daylight Saving Time Guide for Global Teams: How to Avoid Scheduling Chaos

Daylight Saving Time (DST) is one of the biggest sources of confusion when scheduling across time zones. Twice a year, clocks shift forward or backward—but not everywhere, and not on the same dates. For a team that's entirely inside one country, DST is a minor annoyance. For a global team or BPO spanning the US, Europe, and Asia, it's four separate transition events per year, each capable of silently moving your meetings, shift handoffs, and SLA windows by an hour.

This guide covers when the changes happen, who skips them entirely, and the operational playbook for getting through transition weeks without chaos.

What DST Is and Why Ops Teams Care

Daylight Saving Time is the practice of setting clocks forward one hour during warmer months to extend evening daylight, then back again in autumn. The clock change itself is trivial. What matters operationally is the second-order effect: the offset between any DST location and any non-DST location changes twice a year, and the offset between two DST regions on different schedules (like the US and EU) changes four times a year for a few weeks at a stretch.

Concretely: New York to Bengaluru is 10 hours 30 minutes in winter (EST vs. IST) but 9 hours 30 minutes in summer (EDT vs. IST)—because India never changes its clocks while New York does. Every recurring commitment between those two cities moves by an hour, twice a year, from one side's point of view. Whoever forgets is an hour late or an hour early.

The DST Calendar: Who Changes, and When

Region	Clocks forward	Clocks back	2026 dates
United States and Canada (most areas)	Second Sunday in March, 2 AM local	First Sunday in November, 2 AM local	Mar 8 / Nov 1
European Union and UK	Last Sunday in March, 1 AM UTC	Last Sunday in October, 1 AM UTC	Mar 29 / Oct 25
Southeastern Australia (NSW, VIC, SA, TAS, ACT)	First Sunday in October	First Sunday in April	Oct 4 / Apr 5
New Zealand	Last Sunday in September	First Sunday in April	Sep 27 / Apr 5

Three details in that table repay attention. First, the US and EU are misaligned by two to three weeks in spring and one week in autumn—the "shoulder weeks" covered below. Second, the EU changes at a fixed UTC instant, so all EU countries switch simultaneously; the US changes at 2 AM local time, so its zones switch one after another. Third, Southern Hemisphere dates run opposite to the north, because their seasons are reversed—Sydney is on DST during the northern winter.

And a long list of places never changes clocks at all:

• Asia: India (UTC+5:30), China (UTC+8), Japan (UTC+9), the Philippines (UTC+8), and nearly every other Asian country—which is why major BPO delivery hubs like Manila, Bengaluru, and Hyderabad have rock-steady local time while their US and European clients drift around them
• Latin America: Brazil abolished DST in 2019; Mexico abolished it in 2022 for almost the whole country (a strip of northern border municipalities still follows the US schedule). Mexico City is now UTC-6 year-round
• Within the US: Arizona (except the Navajo Nation) and Hawaii stay on standard time permanently
• Within Australia: Queensland, Western Australia, and the Northern Territory skip DST even as the southeast observes it
• UTC itself: Coordinated Universal Time never shifts, which is exactly what makes it useful as a reference (see our guide on converting UTC to local time)

The Shoulder Weeks: When Familiar Offsets Temporarily Break

Because the US and Europe change on different dates, there are two windows each year when the usual transatlantic offsets are wrong:

• Spring (in 2026: March 8–29): The US has sprung forward but Europe hasn't. New York–London is 4 hours instead of the usual 5. Your 10 AM ET / 3 PM London standing call becomes 10 AM ET / 2 PM London for three weeks.
• Autumn (in 2026: October 25 – November 1): Europe has fallen back but the US hasn't. Again 4 hours instead of 5, for one week.

The same logic hits every mixed pairing. During US-only transition windows, US–India offsets have already shifted while US–UK ones haven't. And any US–Australia pairing changes four times a year—both ends move, in opposite directions and in different months. New York–Sydney swings between 14, 15, and 16 hours depending on which combination of EDT/EST and AEDT/AEST is in force.

If you take one habit from this guide: never extrapolate an offset you verified last month. Check the actual date in a DST-aware timezone converter, which applies the correct rules per location per date automatically.

Operational Gotchas Beyond Meetings

For BPOs and 24/7 operations, DST is more than a calendar nuisance:

The overnight shift is the wrong length twice a year. In the US spring transition, 2:00–3:00 AM local time doesn't exist—an overnight agent scheduled 11 PM–7 AM works only 7 hours. In November, the 1:00–2:00 AM hour occurs twice, and that same shift is 9 hours of actual work. Payroll must reflect hours actually worked, and coverage plans must account for the stretched or compressed night. Teams often discover this via a confused agent or a payroll dispute rather than by planning.

Handoff times move in non-DST sites. If your Manila floor hands off to a US team "when the US day starts," that handoff moves an hour in Manila local time every March and November—Manila's clocks never changed, but the anchor did. Rosters that hard-code Manila local times quietly detach from the client's business day. This is a recurring theme in multi-client BPO operations across time zones, where different clients' DST regimes can move independently.

SLA measurement windows shift. A contract defining support hours as "8 AM–8 PM Eastern" implicitly moves in UTC terms twice a year. Monitoring dashboards, alert schedules, and report cutoffs pinned to UTC (or to a non-DST location's time) will misalign with the contractual window unless someone updates them.

Recurring calendar events are only as good as their timezone setting. An event correctly pinned to "10 AM America/New_York" stays right for New York and adjusts everyone else automatically. An event created in UTC, or communicated as fixed local times in an email ("10 AM NY / 8:30 PM Bengaluru"), goes stale at the next transition. The tool usually isn't the problem—the copy-paste around it is.

Your DST Playbook

1. Pin every recurring event to a named timezone, ideally the timezone whose participants anchor the meeting (e.g., the client's). Modern calendars handle the rest.
2. Keep a transition calendar. Four dates matter to most global teams each year: the US spring and fall changes, and the EU spring and fall changes (plus Southern Hemisphere dates if relevant). Put them in the team calendar with a reminder one week ahead.
3. Run a transition-week review. In the week before each change, review recurring meetings, shift rosters, handoff times, and any UTC-pinned automation. Confirm times with external participants explicitly: "This call stays 10 AM ET, which will now be 7:30 PM for Bengaluru."
4. Communicate in two zones plus the delta. "10 AM ET / 3 PM London (note: 2 PM London during March 8–29)" prevents nearly all confusion.
5. Use UTC as the reference for infrastructure, local zones for humans. Servers, logs, and cron jobs belong in UTC precisely because it never moves; human commitments belong in named local zones because that's what participants live in.
6. Audit the overnight shift. Before each US transition, decide explicitly how the 7-hour March night and 9-hour November night will be staffed and paid.

Worked Example: A Monthly Call Across Three Regimes

Scenario: A monthly review with participants in New York (US DST), London (EU DST), and Tokyo (no DST), normally at 9 AM New York time.

• Summer (EDT/BST): 9 AM New York = 2 PM London = 10 PM Tokyo (Tokyo is UTC+9, EDT is UTC-4, so Tokyo runs 13 hours ahead).
• Winter (EST/GMT): 9 AM New York = 2 PM London = 11 PM Tokyo (Tokyo now runs 14 hours ahead of EST, since New York fell back while Tokyo stayed put).
• Shoulder weeks (March 8–29 and October 25–November 1, 2026): London is only 4 hours ahead of New York, so the call is 1 PM London, not 2 PM, while Tokyo stays at 10 PM.

The Tokyo participant experiences a meeting that wanders between 10 PM and 11 PM across the year despite "never changing"; the London participant gets a surprise hour twice a year. Pinning the event to America/New_York and letting a DST-aware tool render everyone's local time is the entire fix—plus one courtesy note to Tokyo each transition, since a late-evening hour shift matters to a human even when the calendar handles it correctly.

Frequently Asked Questions

Why don't India, China, or Japan use DST? DST's rationale is shifting daylight into the evening at higher latitudes, where summer and winter day lengths differ dramatically. Much of Asia sits at latitudes where the difference is small, and several countries that experimented with DST (Japan briefly after WWII, China in the 1980s, India never nationally) judged the disruption not worth it. For schedulers, the reason matters less than the fact: their offsets are constants.

Is the US or EU getting rid of DST? Both have debated it—the US Senate passed the Sunshine Protection Act in 2022 but it never became law, and an EU proposal to end seasonal changes has been stalled since 2019. Until legislation actually passes somewhere, plan on the current rules continuing, and rely on tools that track the IANA timezone database, which is updated whenever any jurisdiction changes its rules.

Which direction does my meeting move for non-DST participants? When the US springs forward, a meeting pinned to US time moves one hour earlier in non-DST locations' local time (10 AM EST = 8:30 PM IST becomes 10 AM EDT = 7:30 PM IST). When the US falls back, it moves an hour later. If the event is pinned to the non-DST side instead, the US participants feel the shift.

What's the safest way to schedule across a transition date? State the anchor timezone explicitly ("10 AM America/New_York"), send calendar invites rather than prose times, and double-check anything created before the transition that lists multiple local times in text.

Conclusion

DST chaos is predictable chaos: the dates are known years in advance, the rules are public, and the failure modes—stale offsets, hard-coded local times, unaudited overnight shifts—repeat every March, April, September, October, and November somewhere in the world. A team that pins events to named timezones, keeps the four key transition dates visible, and uses DST-aware tooling turns transition weeks into non-events.

For teams managing complex operations across multiple time zones, consider a workforce management platform that handles DST, scheduling, and compliance automatically.

Related Guides:

• How to convert UTC to local time zone - Learn UTC conversion methods
• Best time to schedule meetings across US time zones - US-specific scheduling tips
• Multi-client BPO operations - Managing operations across time zones

---

Want to avoid DST scheduling errors? Try Timezone Assistant—it automatically accounts for Daylight Saving Time in all timezones, so you never have to worry about time changes again.