Daylight Saving Time 2026: Every Transition Date That Will Quietly Shift Your Team's Meeting Times
Published August 24, 2026 by SyncHours Team
"Daylight Saving Time" reads like one global event, but it's actually four or five independent regional switches a year, on different dates, in different directions, and a growing list of countries that have opted out of the whole system entirely. A recurring meeting locked to "9am my time" doesn't stay at a fixed time for everyone else on the call — it drifts by an hour, twice a year, for exactly as long as it takes every region involved to catch up with each other.
2026 transition dates, region by region
| Region | Clocks forward (lose an hour) | Clocks back (gain an hour) |
|---|---|---|
| United States & Canada | Sun, Mar 8, 2026 | Sun, Nov 1, 2026 |
| European Union & United Kingdom | Sun, Mar 29, 2026 | Sun, Oct 25, 2026 |
| Australia (NSW, VIC, SA, TAS, ACT) | Sun, Oct 4, 2026 | Sun, Apr 5, 2026 |
| New Zealand | Sun, Sep 27, 2026 | Sun, Apr 5, 2026 |
"Clocks forward" and "clocks back" are listed from each region's own local perspective, which is why Australia and New Zealand's columns run opposite to the US and EU's — they're in the Southern Hemisphere, so their DST season is the Northern Hemisphere's winter.
Where DST doesn't apply at all
Just as important for a distributed team: several major population centers never move their clocks, which makes them a fixed point you can schedule around all year. India, China, Japan, and Singapore have never observed DST. Irandropped it in 2022. Mexico abolished it nationwide in 2022 except for a narrow strip of border cities that stay aligned with US clocks. Brazil abolished it in 2019. If your team spans, say, Bangalore and Singapore, the gap between them literally never changes — the only zones you need to track for drift are the ones that actually observe DST somewhere in the chain.
The two windows where a "5-hour gap" quietly becomes a "4-hour gap"
Take a recurring 9:00am EST Monday standup with a London-based teammate. For most of the year, the US/UK gap is a stable 5 hours — 9am EST is 2pm GMT in winter, and 9am EDT is 2pm BST in summer, because both sides shift together. The problem is the three weeks in between, when only one side has moved:
- Mar 8 – Mar 29, 2026: the US has sprung forward to EDT (UTC-4), but the UK hasn't yet — still GMT (UTC+0). The gap narrows to 4 hours, so that same 9am EDT standup lands at 1pm GMT, an hour earlier than the "usual" 2pm the London teammate has in their head.
- Oct 25 – Nov 1, 2026: the reverse happens. The UK has fallen back to GMT, but the US is still on EDT for one more week. The gap is 4 hours again, so the meeting is at 1pm GMT rather than the 2pm everyone expects for that time of year.
Six weeks of quiet one-hour drift a year, concentrated into two three-week windows, for just this one pair. Teams spanning three or four regions with staggered DST rules — say, US, EU, and Australia — get overlapping mismatch windows that can shift a meeting by an hour in either direction more than once in the same month. See the full breakdown of how big these gaps are outside the mismatch windows in golden overlap windows by time zone pair.
Why this hasn't been fixed already
It's not for lack of trying. The EU Parliament voted in 2019 to end the twice-yearly clock change entirely, but implementation has stalled ever since over an unresolved question: which single time zone should each member state permanently keep, standard or daylight? Individual countries switching on different schedules would fragment the EU's internal time zone map worse than the current system does, so as of 2026 the vote remains unimplemented and the biannual switch is still very much in effect. If you're planning recurring meetings more than a year out with EU-based teammates, it's worth a quick recheck closer to the date rather than assuming this guide's dates hold indefinitely.
The fix: stop scheduling from memory
The reliable answer isn't memorizing eight transition dates a year — it's not doing the conversion by hand at all. A calendar invite anchored to a specific date and each attendee's local time zone (rather than a fixed UTC offset typed in once) resolves correctly through every transition automatically, because the underlying IANA time zone database already encodes every rule above. SyncHours' scrubber works the same way — drag through any date on the overlap planner and the working/fringe/rest breakdown updates for whichever set of DST rules is actually in effect that day, rather than the rule that happened to be true when someone last checked.
If you manage a recurring meeting across any of the regions above, put a standing reminder on your own calendar for the week before each transition date in the table — not to manually recompute anything, just to re-confirm the invite still shows the local time you expect for every attendee, since that's the one thing worth a human glance twice a year.