Daylight saving 2026 survival guide — every date that matters

Quick answer

If you only have time for the headline, circle four dates. The rest of this guide is about why those dates matter and what breaks when you ignore them.

The single most important takeaway: the US and the EU do not shift on the same day. The gap between them is wrong for three weeks in March and one week in November. If you have recurring meetings across the Atlantic, that is when they quietly break.

North America

The US and Canada move together on two dates in 2026. Clocks spring forward on Sunday March 8, 2026 at 02:00 local — the second Sunday of March, per the Energy Policy Act of 2005. They fall back on Sunday November 1, 2026 at 02:00 local — the first Sunday of November. Both transitions happen in the small hours of Sunday morning specifically to minimise disruption to scheduled trains, flights, and anyone working a normal Friday night.

Three significant carve-outs. Arizona does not observe DST, except for the Navajo Nation in the northeast corner of the state, which does. So from March 8 onwards, Phoenix is on Mountain Standard Time (UTC-7), which puts it in sync with Pacific Daylight Time — Phoenix and Los Angeles read the same time from March 8 until November 1, then Phoenix is one hour behind LA for the winter. Hawaii stays on Hawaii-Aleutian Standard Time year-round. Saskatchewan is the Canadian carve-out — it stays on Central Standard Time year-round, which means in summer it matches Alberta (Mountain Daylight Time) and in winter it matches Manitoba (Central Standard Time). Yukon also stopped observing DST in 2020 and now stays on Yukon Standard Time (effectively MST) year-round.

There has been on-and-off federal noise about making DST permanent in the US. The Sunshine Protection Act passed the US Senate by unanimous consent in March 2022 but never received a House vote and died at the end of that Congress. It has been reintroduced in every session since, with no movement. Until and unless that changes, the second-Sunday-of-March and first-Sunday-of-November rule continues to hold across the country.

If you coordinate with Canadian colleagues, the only one to watch is Saskatchewan. Everywhere else in Canada — Vancouver, Calgary, Toronto, Montreal, Halifax — observes DST on the US dates and the offsets you have memorised continue to apply.

Europe and the UK

The EU and the UK shift on the last Sunday of March and the last Sunday of October, at 01:00 UTC. In 2026 that is Sunday March 29 in spring and Sunday October 25 in autumn. The UTC anchor is what makes the European transitions clean — all member states shift at the same instant, regardless of their local time zone, so the offsets between European cities never change during the transition. Paris stays one hour ahead of London before, during, and after.

The harmonisation is by EU Directive 2000/84/EC, which the UK kept after Brexit. Iceland, Belarus, Russia, and Turkey all opted out years ago and stay on a single offset year-round. Russia switched to permanent standard time in 2014 after a brief experiment with permanent summer time. Turkey switched to permanent summer time in 2016 and has stayed there. The result is that the gap between Moscow and Berlin widens by an hour in summer and the gap between Istanbul and Brussels does the same.

Then there is the EU's long-running attempt to abolish DST entirely. The European Parliament voted in March 2019 to scrap seasonal clock changes from 2021. The vote followed a public consultation with 4.6 million responses, the largest in EU history, in which 84% of respondents said they wanted clock changes to stop. The proposal then stalled in the Council of the EU because member states could not agree on whether to settle on permanent summer time or permanent winter time, and because no impact assessment had been done. COVID buried it. As of 2026 the directive is unchanged and the twice-yearly shift continues. Do not plan around an abolition that may never come.

The UK reproduced the EU schedule in domestic law after Brexit, so London and continental Europe still shift in lockstep. If that ever changes, the consequences for cross-channel scheduling would be significant — you would suddenly have two separate transition Sundays in March and October, and the broken-windows problem that today exists only between the US and EU would extend to within Europe.

Australia and New Zealand

The southern hemisphere does DST in reverse. Australian states that observe it (New South Wales, Victoria, the ACT, Tasmania, and South Australia) fall back on Sunday April 5, 2026 at 03:00, ending Australian Eastern Daylight Time. They spring forward on Sunday October 4, 2026 at 02:00, starting AEDT again. Queensland, Western Australia, and the Northern Territory do not observe DST at all — Queensland tried it in the early 1990s and abandoned it after a referendum. Brisbane therefore drifts an hour behind Sydney for half the year.

New Zealand has the earliest spring-forward of any major economy: Sunday September 27, 2026 at 02:00, when clocks jump to 03:00 and NZ Daylight Time begins. The fall-back date is the same as Australia's, Sunday April 5, 2026 at 03:00. The early start means that from late September until early October, New Zealand is three hours ahead of Sydney rather than two — a one-week broken window for anyone scheduling between Auckland and the Australian east coast.

The practical implication for transpacific work: if you have a recurring meeting between, say, Sydney and San Francisco, the gap is normally 17 or 18 hours depending on the season. It flexes in both directions during the transition months. In late September and early October, when NZ has shifted and Australia has not and the US has not, you have three separate offsets in motion inside two weeks. There is no clever workaround. Audit the calendar manually.

The broken windows between US and EU/UK transitions

This is the part of the guide that most affects most people. Between Sunday March 8, 2026 (US springs forward) and Sunday March 29, 2026 (EU/UK springs forward), there are three weeks when the gap between New York and London is 4 hours instead of the usual 5. Same between continental Europe and the US East Coast. Same between Berlin and Chicago, Paris and Boston, every transatlantic pair. The cause is mechanical — the US shifted, Europe did not, the gap closed by an hour — but the practical effect is that every recurring meeting set in "London time" now lands an hour earlier in New York for those three weeks.

In autumn it goes the other way. The UK and EU fall back on Sunday October 25, 2026. The US does not fall back until Sunday November 1, 2026. For that one week — October 25 through October 31 — Europe has shifted but the US has not, so the gap is again 4 hours instead of 5. Then the US falls back, the 5-hour gap snaps back into place, and it holds until the following March.

Total: roughly four weeks a year where the textbook offset between the US East Coast and London is wrong by one hour. If you only ever schedule one-off meetings, this barely matters because both sides' calendars will agree on the converted time. The problem is recurring invites that span the transition. Whatever wall-clock time the organiser set will quietly shift on one side and hold on the other, and somebody will be late.

For a side-by-side view of the hours, see our EST vs GMT comparison for winter, EDT vs BST for summer, and EDT vs CEST for the central-European pairing.

Why recurring invites silently break

The mechanics matter here because the failure mode is invisible until it has already happened. Calendar tools store recurring events in one of two ways. The good way: a real IANA time zone identifier ("Europe/London", "America/New_York") is attached to the event, and the recurring rule says "every Tuesday at 14:00 in Europe/London". The client computes the displayed time from the zone plus the date, and the offset handles DST automatically. Attendees in New York see 09:00 in winter, 10:00 during the broken-window weeks of March, then 09:00 again from late March onwards. This is what you want.

The bad way: the event is stored as a "floating time" or with an abbreviation like EST or GMT. Floating times have no zone — they display as whatever local time the client is set to, with no conversion. Abbreviations like EST are unambiguous in only one direction (EST is permanently UTC-5) and so they freeze the event to a fixed offset even when the underlying zone shifts to EDT (UTC-4). Either way, the event drifts during DST transitions and the organiser has no idea.

Outlook is the worst offender. Older versions, and many enterprise configurations, default to creating events without a zone identifier. The "all attendees same time" option is particularly dangerous — it locks the wall-clock time without preserving the zone, which means during DST one side shifts and the other does not. Google Calendar handles zones correctly by default, but if you import an Outlook .ics with no zone identifier the same problem propagates.

The symptom is always the same. A recurring meeting that has run cleanly for months suddenly has one side arriving an hour late or an hour early on the Monday after a transition Sunday. Nobody fixes the underlying event — they just show up for the new wrong time and life carries on. Until the next transition.

Practical fixes

The fixes are not glamorous. They are auditing, conventions, and a habit. In rough order of impact:

1. Always create recurring events with an explicit IANA time zone. Not EST. Not GMT. America/New_York and Europe/London. The IANA database handles DST transitions automatically and is updated whenever a country changes its rules. Abbreviations are a permanent source of bugs.

2. Audit recurring invites the week before each transition. Specifically: the week of February 28, 2026 (before US springs forward March 8), the week of March 22 (before EU/UK springs forward March 29), the week of October 18 (before EU/UK falls back October 25), and the week of October 25 (before US falls back November 1). Look at every recurring invite that has attendees in two regions. Confirm the wall-clock time on both sides will be what you expect after the transition.

3. For one-off meetings across DST boundaries, paste UTC into the invite description. The text "14:00 London / 09:00 New York / 18:00 UTC" in the body is bulletproof. Whatever the calendar tool does to your recipient, they can fall back to the UTC string and arrive on time.

4. Prefer scheduling tools that show both sides. Calendly, Cal.com, Reclaim, Motion — they all render the meeting in the recipient's zone and handle DST correctly on both ends. Plain email back-and-forth with "does 2 PM work?" is the failure mode this guide exists to prevent.

5. If you organise recurring transatlantic calls, set them in the more eastern zone. The reasoning: Europe has more rigid 9-5 working hours than the US, so anchoring to London or Berlin and letting New York or San Francisco drift forward an hour for three weeks in March is less disruptive than the opposite. The Europeans will not notice. The Americans will, but they were already up.

Tools

The widget below is the same time zone converter we use ourselves. It handles every transition in this guide — including the broken-window weeks — by reading from the IANA tz database. New York and London are pre-loaded for the canonical transatlantic pairing.

For scheduling across more than two zones, the meeting scheduler is the better tool. It shades the working-hours overlap across every zone you add and flags the windows where a transition is about to land.

For the side-by-side hour grids, bookmark the comparisons that match your most frequent pairings: EST vs GMT for transatlantic winter, EDT vs BST for transatlantic summer, and EDT vs CEST for the US-to-continental-Europe pairing.

Finally, a tool that solves an adjacent problem: if you invoice clients in another time zone — which is to say, in another currency — the cost of FX margins from a regular bank typically dwarfs whatever you saved by scheduling well. Wise handles cross-border payments at the mid-market rate, with the spread you would otherwise pay surfacing as a visible fee instead of a hidden one.

FAQ