London Is 5 Hours Ahead of New York — Except for 28 Days a Year
Nearly every guide to scheduling across time zones argues that you should use a converter. Almost none of them show you the thing that makes it necessary: the gap between two cities is not a constant. We measured every city pair we publish, every day of 2026, and most of them move.
The 28 Days Nobody Puts in the Calendar
The United States moves its clocks forward on the second Sunday in March and back on the first Sunday in November. The UK and the EU move on the last Sunday in March and the last Sunday in October. Those dates do not line up, and in 2026 they leave two windows where the transatlantic gap is not what either side expects:
- 8 March – 29 March 2026 — three weeks. The US has sprung forward; the UK has not. London is 4 hours ahead of New York, not 5.
- 25 October – 1 November 2026 — one week. The UK has fallen back; the US has not. Same result, opposite cause.
Twenty-eight days. A recurring 3pm London call with New York lands at 10am for four of those weeks instead of the usual 11am — or the other way round, depending on which calendar created the series. Nothing warns you. The invite is not wrong in any way software can detect; it is doing exactly what it was told.
The same shape shows up on every transatlantic pair: Chicago–London, London–Toronto, New York–Paris and London–Los Angeles all spend exactly those 28 days off their usual offset. It is one cause with many symptoms.
All 17 Pairs, Measured
Every city pair with a page on this site, sampled at 12:00 UTC on each of the 365 days of 2026. “Off usual” counts the days spent away from that pair’s most common gap.
| Pair | Gaps | Off usual | Distribution |
|---|---|---|---|
| London → Sydney | 3 | 183d | 9h for 182d · 11h for 155d · 10h for 28d |
| New York → Sydney | 3 | 183d | 14h for 182d · 16h for 127d · 15h for 56d |
| Dubai → London | 2 | 155d | −3h for 210d · −4h for 155d |
| Hong Kong → London | 2 | 155d | −7h for 210d · −8h for 155d |
| London → Mumbai | 2 | 155d | +4h30 for 210d · +5h30 for 155d |
| London → Singapore | 2 | 155d | 7h for 210d · 8h for 155d |
| London → Tokyo | 2 | 155d | 8h for 210d · 9h for 155d |
| New York → Mumbai | 2 | 127d | +9h30 for 238d · +10h30 for 127d |
| New York → Tokyo | 2 | 127d | 13h for 238d · 14h for 127d |
| Chicago → London | 2 | 28d | 6h for 337d · 5h for 28d |
| London → Los Angeles | 2 | 28d | −8h for 337d · −7h for 28d |
| London → New York | 2 | 28d | −5h for 337d · −4h for 28d |
| London → Toronto | 2 | 28d | −5h for 337d · −4h for 28d |
| New York → Paris | 2 | 28d | 6h for 337d · 5h for 28d |
| London → Berlin | 1 | — | 1h, every day of the year |
| London → Paris | 1 | — | 1h, every day of the year |
| Los Angeles → New York | 1 | — | 3h, every day of the year |
Two pairs take three distinct values rather than two. London–Sydney and New York–Sydney sit at 9, 10 and 11 hours (and 14, 15 and 16) across the year, because the northern and southern daylight-saving seasons overlap at their edges instead of lining up. Both spend 183 days — over half the year — away from their commonest gap. If you work with Australia, there is no offset worth memorising.
What This Means for Scheduling
The practical rule is short: never store an offset, store the two cities. An offset is a snapshot that expires; a city name resolves correctly on any date. This is exactly what the tz database is for, and it is why the identifier is Europe/London and not GMT — the first knows about British Summer Time, the second does not.
Three habits follow from the data above:
- Write the city into the invite. “15:00 London / 11:00 New York” is checkable by both parties. “15:00 GMT” is wrong for eight months of the year, because London is on BST for those months and is not on GMT at all.
- Re-check anything recurring in late March and late October. Those are the two weeks when the transatlantic pairs drift. Put a reminder in the calendar if it helps.
- Convert the specific date, not “now”. A meeting three weeks out may fall on the other side of a transition. A converter that only answers for the current moment cannot tell you that.
If you want the mechanics rather than the rules, we wrote them up separately: how to convert time between cities walks the three-step method, daylight saving time explained covers why the gap moves at all, and UTC, GMT and offsets explains why “Europe/London” beats “BST”.
Mistakes Worth Skipping
Storing the gap instead of the zones
The single most common one. "London is 5 hours ahead of New York" is true for 337 days of 2026 and false for 28. A meeting series pinned to a remembered gap drifts by an hour twice a year, and it drifts silently — nobody gets a warning, the invite just fires at the wrong time. Store the two zone names and let the machine do the arithmetic.
Trusting three-letter abbreviations
IST is India Standard Time, Israel Standard Time and Irish Standard Time. CST is used for both US Central and China Standard. BST means British Summer Time in London and Bangladesh Standard Time elsewhere. None of these are standardised, and none of them are what the tz database actually keys on — it uses region names like Europe/London. Our converter pages spell out which one is meant.
Assuming everyone shifts on the same weekend
They do not, and this is where the 28-day windows come from. The EU and UK move on the last Sunday in March; the US and Canada move three weeks earlier, on the second Sunday. In autumn the order reverses. During each gap the transatlantic offset is off by an hour from what both sides expect.
Forgetting the half-hour and 45-minute zones
India sits at UTC+5:30, Nepal at +5:45, and parts of Australia at +9:30 or +10:30. New York to Mumbai is 9 hours 30 in winter and 10 hours 30 in summer — never a whole number. Rounding it makes the meeting half an hour wrong, which is exactly long enough to be annoying and short enough that nobody investigates.
Reading the southern hemisphere backwards
Sydney is on summer time when London is not. That is why London–Sydney takes three different values in a year instead of the usual two: the two DST seasons overlap at the edges rather than lining up. It spends 183 days of 2026 away from its most common gap — more than half the year.
Check This Yourself
Every figure on this page came out of the snippet below. It has no dependencies — it reads the same IANA rules your browser already ships. Paste it into any browser console or run it with Node, and change the two zone names to check a pair we do not publish.
const A = 'Europe/London', B = 'America/New_York', YEAR = 2026;
const offset = (tz, d) => {
const f = new Intl.DateTimeFormat('en-US', { timeZone: tz, hour12: false,
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit' });
const p = Object.fromEntries(f.formatToParts(d)
.filter(x => x.type !== 'literal').map(x => [x.type, x.value]));
return (Date.UTC(p.year, p.month - 1, p.day, p.hour % 24, p.minute)
- Math.floor(d / 60000) * 60000) / 3600000;
};
const seen = {};
for (let i = 0; i < 365; i++) {
const day = new Date(Date.UTC(YEAR, 0, 1 + i, 12));
const gap = offset(A, day) - offset(B, day);
seen[gap] = (seen[gap] || 0) + 1;
}
console.log(seen); // { '5': 337, '4': 28 }Two caveats we would rather state than bury. The tz database is revised several times a year as governments change their rules, so a run in 2027 may give different numbers for 2026 if a rule was amended retroactively — that is the database working, not a bug. And sampling at noon UTC counts whole days: a transition happening at 01:00 local puts the changeover day in one bucket rather than splitting it. Neither affects the conclusion, but both affect the last digit.
Common Questions
How many days a year is London 5 hours ahead of New York?
In 2026, 337 of them. For the other 28 the gap is 4 hours: from 8 March to 29 March, and again from 25 October to 1 November. Both windows exist because the United States changes its clocks on the second Sunday in March and the first Sunday in November, while the UK and EU change on the last Sunday in March and the last Sunday in October. For three weeks each spring and one week each autumn, one side has moved and the other has not. This is the single most common source of a missed transatlantic call, and it is invisible to anyone working from a remembered offset.
Do time zone gaps really change during the year?
For most international pairs, yes. We measured all 17 unique city pairs we publish, every day of 2026, against the IANA time zone database: 14 of them take more than one value during the year. Only three hold constant — London to Paris, London to Berlin and Los Angeles to New York — and all three are pairs where both cities sit inside the same daylight-saving regime and therefore shift together on the same date. The general rule is that a gap is stable only when both ends change their clocks on the same day, or when neither does.
What does a time zone converter actually do that mental arithmetic does not?
It applies the correct offset for the specific date you are asking about, rather than the one that is true most of the time. A converter that is doing its job resolves both ends to IANA zone identifiers, looks up the offset in force on that date, and handles half-hour zones and the date line without you thinking about it. Our converter is built this way and runs entirely in your browser — the time zone rules come from your device, so there is no request to a server and nothing about your meeting leaves the page.
Why do three-letter time zone abbreviations cause problems?
Because they are ambiguous and unofficial. IST alone can mean India (UTC+5:30), Israel (UTC+2 or +3) or Ireland (UTC+1). CST covers US Central (UTC−6 or −5) and China Standard (UTC+8) — a fourteen-hour disagreement. The tz database avoids the problem entirely by keying on geographic identifiers such as America/Chicago or Asia/Shanghai, which encode the full history of that place's offsets and DST rules. When you write an invite, name the city, not the abbreviation.
Where does the time zone data itself come from?
The IANA time zone database, maintained collaboratively and released several times a year as governments announce changes. It is the source every operating system and browser ultimately depends on, which is also why an up-to-date device generally converts correctly and a hardcoded table in a spreadsheet does not. Our tools read the rules already present in your browser rather than shipping a copy, so they stay current as your device updates.
Our time zone converter resolves both ends to IANA zones and applies the rules in force on the date you pick — half-hour offsets and transition weeks included. It runs entirely in your browser: no account, and nothing about your meeting is sent anywhere.
Open the time zone converter →Also useful: the world clock for several cities at once, the meeting planner for finding a slot that works on both sides, and per-pair pages like London to New York or London to Sydney.