The offset between two time zones is not a constant. London is five hours ahead of New York for most of the year and four hours ahead during two windows, because the United States and the European Union change their clocks on different dates. In 2026 the United States moves forward on 8 March and the EU on 29 March, leaving a 21-day window; in autumn the EU falls back on 25 October and the United States on 1 November, leaving 7 days.
A meeting fixed as "3pm London, 10am New York" is therefore wrong for four weeks a year, and it is wrong in a way calendars usually handle correctly and humans usually do not.
When do the clocks actually change?
On different rules in each region, all expressed as an nth weekday rather than a date — which is why the gaps between them vary from year to year.
| Region | Spring forward | Fall back |
|---|---|---|
| United States | Second Sunday in March | First Sunday in November |
| European Union and UK | Last Sunday in March | Last Sunday in October |
| Australia (eastern states) | First Sunday in October | First Sunday in April |
In 2026 that gives the US 8 March and 1 November, the EU 29 March and 25 October. In 2027 the US dates move to 14 March and 7 November while the EU dates move to 28 March and 31 October — so the spring window shrinks from 21 days to 14. The mismatch is not a fixed number of weeks and cannot be memorised.
The southern hemisphere runs the opposite way, so Sydney and London swing between 9, 10 and 11 hours apart across a year.
Which meeting time actually moves?
Whichever one is not anchored. A recurring event created in a calendar carries the time zone it was created in, so a meeting set at 3pm London stays at 3pm London and the New York attendee sees it move to 10am for three weeks in March.
That is correct behaviour and it still catches people, because the person who created the meeting never sees anything change. The attendee in the other zone experiences a meeting that silently shifts an hour twice a year.
The fix is to agree explicitly whose local time is fixed, and to say so in the invitation. "3pm London" is unambiguous. "3pm" is a bet on where the reader is.
Where do the rules come from?
The IANA time zone database, which every operating system and browser carries a copy of. It is updated several times a year as countries change their rules, and those changes are frequent — governments move dates, adopt or abandon daylight saving, and occasionally change their standard offset entirely.
This is why a time zone converter should read the browser’s own copy of that data rather than a table of offsets stored in the page. A stored table is correct on the day it is written and quietly wrong afterwards, and the failure mode is a meeting invitation rather than an error message.
It is also why zones are named after cities rather than offsets. America/New_York is a set of rules over time; UTC−5 is a single number that is only true for part of the year.
What breaks besides meetings?
Three things, all with the same root cause.
- Overnight shifts and rotas. A shift crossing the change is 23 or 25 hours long, and payroll systems that assume 24 get it wrong twice a year.
- Times that occur twice, or not at all. When the clock goes back, 1:30am happens twice; when it goes forward, it does not happen. A reminder set for a time that does not exist has to be resolved somehow, and different systems resolve it differently.
- Scheduled jobs. Anything running at a fixed local time either runs twice or is skipped on the changeover night, which is why infrastructure schedules are normally written in UTC.
Is UTC the same as GMT?
For everyday purposes yes, and they are defined differently. GMT is a time zone based on the Greenwich meridian; UTC is a time standard maintained by atomic clocks and kept within a second of astronomical time.
The distinction matters in two places. UTC never observes daylight saving, so London is UTC+0 in winter and UTC+1 in summer while remaining in the same zone throughout — which is why "GMT" written on a summer meeting invitation from London is usually wrong by an hour. And UTC has historically absorbed leap seconds, which GMT as a zone does not have a mechanism for.
Questions people ask
What does the DST tag mean? That the zone currently observes daylight saving. Those are the zones where a booking made in March moves in October, so they are the ones worth checking twice.
Can I add any city? Any city in the IANA database, which is most of them. Searching by city is more reliable than searching by offset, because the offset is the thing that changes.
Why do some countries not change at all? Most of Asia, Africa and South America do not observe daylight saving, and several countries have abandoned it recently. Zones without it are the easy ones — their offset really is constant.
What about half-hour offsets? India, Iran, parts of Australia and Newfoundland run on offsets of 30 or 45 minutes from UTC. They are ordinary zones and they break any mental model built on whole hours.
State the anchor zone in the invitation and let the software handle the rest. The time zone converter reads the live rules from the browser and marks the zones that observe daylight saving, the age calculator handles the other kind of calendar arithmetic, and the typing speed test is there for whatever you were warming up for.