Why Time Zone Offsets Keep Changing
The difference between two cities is not a property of those cities. It is a property of the date, and for a few weeks each year it is not the number everyone has memorised.
In short
- An offset belongs to a moment in time, not to a pair of cities.
- Europe and North America change their clocks on different dates, opening a gap of a few weeks.
- Not every zone is a whole number of hours from UTC — several are on the half hour.
- The southern hemisphere runs its summer time in the opposite half of the year.
The two-week window nobody plans for
London is usually five hours ahead of New York. Madrid is usually six. Everybody who works across the Atlantic knows this, and for most of the year it is correct.
It stops being correct twice a year, because the two continents do not change their clocks on the same day. The United States moves to daylight saving time on the second Sunday in March; the European Union moves on the last Sunday in March. In the interval, North America has already sprung forward and Europe has not, so every transatlantic offset is one hour smaller than usual.
The same thing happens in reverse in the autumn, when the EU falls back on the last Sunday in October and the US waits until the first Sunday in November.
| Period | Madrid → New York | London → New York |
|---|---|---|
| Most of the year | −6 hours | −5 hours |
| Mid-March to late March | −5 hours | −4 hours |
| Late October to early November | −5 hours | −4 hours |
A recurring meeting set up in February and left alone will drift by an hour for one of the participants during these windows. This is the single most common cause of somebody joining a transatlantic call exactly one hour late.
Offsets belong to instants, not to places
The correct way to think about this is that "Madrid" does not have an offset. A specific moment in Madrid has one. Asking "what is the difference between Madrid and New York" is an incomplete question until you supply a date.
This is why reliable software never stores a time as a local clock reading plus a remembered offset. It stores either an absolute instant, or a local time together with the zone name — "Europe/Madrid" rather than "UTC+1" — and works out the offset for the date in question when it needs to display something.
The zone names come from the IANA time zone database, which records every historical and scheduled rule change for every region on earth. It is updated several times a year, because governments keep changing their minds.
Not every offset is a whole hour
Several hundred million people live in zones that are offset by a fraction of an hour, and code that assumes whole hours breaks for all of them.
| Zone | Offset from UTC | Note |
|---|---|---|
| India (Asia/Kolkata) | +05:30 | A single zone for the whole country |
| Iran (Asia/Tehran) | +03:30 | |
| Newfoundland (America/St_Johns) | −03:30 | Observes daylight saving too |
| Nepal (Asia/Kathmandu) | +05:45 | A 45-minute offset |
| Chatham Islands (Pacific/Chatham) | +12:45 | A 45-minute offset with DST |
India is a useful test case for any date handling: a single zone spanning the whole country, offset by half an hour, with no daylight saving at all.
The southern hemisphere runs the other way
Australia and New Zealand observe daylight saving during the northern winter, so the offset between London and Sydney swings by two hours across the year rather than staying put — and for a few weeks it swings by one, when only one of the two has changed.
Australia adds a further complication: not all states observe daylight saving. Queensland does not, while New South Wales does, so Brisbane and Sydney share a clock for half the year and differ by an hour for the other half despite being on the same coast.
Times that happen twice, and times that never happen
When the clocks go back, the hour before the change repeats. A local time of 01:30 on that morning occurs twice, and refers to two different instants an hour apart. When the clocks go forward, that hour is skipped entirely: 02:30 simply does not exist on that date.
Any system that lets someone enter a local time has to decide what to do with these. Scheduling something for 02:30 on a spring-forward morning has no valid answer, and a booking made for 01:30 on an autumn morning is genuinely ambiguous. Software that silently picks one is storing something the user did not necessarily mean.
Practical rules
For anything that crosses a zone boundary, three habits remove almost all of the risk.
- Write the zone, not the offset. "14:00 CET" is better than "14:00 UTC+1", because the zone name stays correct after the clocks change and the offset does not.
- For a fixed instant that must not move — a launch, a market open, a deadline — state it in UTC and let each reader convert.
- Check offsets around the change dates specifically, rather than assuming the number you used last month still applies.
Frequently Asked Questions
Why is the time difference between London and New York sometimes four hours?
Because the United States moves to daylight saving time on the second Sunday in March and the European Union waits until the last Sunday. In that gap North America has sprung forward and Europe has not, so the usual five-hour difference is temporarily four. The same happens in reverse between late October and early November.
Is the offset between two cities fixed?
No. An offset belongs to a moment in time, not to a pair of places. The question "what is the difference between Madrid and New York" cannot be answered without a date, because the answer changes at least four times a year.
Which time zones are not a whole number of hours from UTC?
India is at UTC+05:30, Iran at +03:30 and Newfoundland at −03:30. Nepal is at +05:45 and the Chatham Islands at +12:45. Any calculation that assumes whole-hour offsets gives wrong answers for hundreds of millions of people.
What happens to a time that falls in the skipped hour?
It does not exist. When clocks go forward, local times in that hour — often 02:00 to 03:00 — are simply skipped on that date, so a meeting scheduled for 02:30 has no valid instant. When clocks go back, the repeated hour means a local time occurs twice and is genuinely ambiguous.
Why should I write the zone name rather than the offset?
Because a zone name like "Europe/Madrid" stays correct after a clock change, while a fixed offset like "UTC+1" becomes wrong. Zone names also carry the full history of rule changes, which is what lets software calculate a past or future date correctly.