Why Cross-Time-Zone Meetings Shift During Daylight Saving Time

Daylight saving time (DST) feels like a local inconvenience — you lose an hour of sleep, you nudge your microwave clock, done. But it causes a subtler problem for anyone who works across time zones: the gap between two places isn't fixed all year. It's fixed most of the year, and then temporarily different for a window of one to three weeks, twice a year, whenever the two regions involved change their clocks on different calendar dates. If a meeting was set using a plain fixed offset ("we talk at UTC-5") instead of a timezone-aware calendar, it silently lands at the wrong local time for one side during that window. Our time zone converter and world clock both compute the live offset for a specific date rather than a rule of thumb, which is exactly what avoids this.

The rule: the US and Europe don't change clocks on the same day

The United States and the European Union both observe daylight saving time, but under different rules. Since the US Energy Policy Act of 2005 took effect in 2007, US clocks move forward on the second Sunday in March and back on the first Sunday in November. The EU (and the UK, which keeps the same dates post-Brexit) uses a different rule: clocks move forward on the last Sunday in March and back on the last Sunday in October.

In 2026, that works out to:

United States: clocks spring forward on Sunday, March 8, 2026, and fall back on Sunday, November 1, 2026.
European Union / UK: clocks spring forward on Sunday, March 29, 2026, and fall back on Sunday, October 25, 2026.

Because these dates almost never line up, there's a stretch every spring where the US has already moved to daylight time but Europe hasn't yet, and a shorter stretch every fall where Europe has already fallen back but the US hasn't. During each of those windows, the time difference between the two regions is one hour off from what it is the rest of the year.

A worked example: New York and London

Take New York (US Eastern) and London (UK), using their standard three-letter offset names:

Winter (before March 8, 2026): New York is on EST (UTC−5), London is on GMT (UTC+0). The gap is 5 hours.

The spring gap window (March 8–29, 2026): New York has already sprung forward to EDT (UTC−4); London is still on GMT (UTC+0). The gap shrinks to 4 hours — a full hour less than usual, for three straight weeks.

Summer (after March 29, 2026): London has now also sprung forward, to BST (UTC+1). New York (EDT, UTC−4) and London (BST, UTC+1) are back to a 5-hour gap — same as winter, just with both clocks shifted forward.

The same thing happens in reverse each fall, just with a shorter window: London falls back to GMT on October 25, 2026, while New York doesn't fall back to EST until November 1. For that one week, the gap is temporarily 4 hours instead of 5, before settling back to 5 once the US catches up.

A recurring 9:00 a.m. New York call that's meant to land at 2:00 p.m. in London will actually land at 1:00 p.m. London time during each of these windows — not because anyone made a mistake, but because the underlying offset genuinely changed for a few weeks.

It's worse with places that never change their clocks at all

Not every country observes daylight saving time. Most of Asia and Africa stay on one fixed offset year-round — China, Japan, and India among them. Within the US, Arizona (outside the Navajo Nation) and Hawaii don't observe it either. A meeting between London and Tokyo, for instance, doesn't get a temporary multi-week "gap window" the way New York–London does — since Tokyo (JST, UTC+9) never moves, the London–Tokyo gap simply steps permanently between 9 hours (UK winter, GMT) and 8 hours (UK summer, BST) the moment London's clocks change, and stays at that new gap until London's next transition. It's a cleaner shift than the double-transition US–Europe case, but it's still a shift that a fixed mental "there's a 9-hour difference" assumption will get wrong for half the year.

How to actually avoid the mix-up

Three habits prevent the whole category of error:

1. Schedule by timezone, not by a fixed offset. Calendar invites that store an actual IANA time zone (like "America/New_York" or "Europe/London") recalculate the correct local time automatically as DST rules apply on each side. An invite that just says "3:00 PM UTC" every week will drift relative to whichever local time you actually meant.

2. Check the specific date, not "today." Because the offset between two zones can change over the following weeks, converting a time for "right now" isn't reliable if you're booking something further out. Our meeting time finder lets you check overlapping working hours for a specific date, and the world clock shows several cities at once so you can sanity-check a date before it's finalized.

3. Flag the transition windows on your calendar. If you regularly work with both US and European colleagues, mark the two or three weeks around March and late October each year — those are the exact windows above where a mismatch is most likely, so it's worth double-checking any meeting scheduled to land inside one.

None of this is a flaw in any particular calendar app — it's a real consequence of two regions choosing different transition dates for the same underlying idea. Once you know the gap windows exist and roughly when they land, checking a live tool for the actual date takes the guesswork out of it.