Time Zone Converter
Converts a time between any two zones, following daylight saving on the date you pick.
Last updated
Your details
Daylight saving depends on the date — the offsets are read for the day you pick.
As HH:MM on the 24-hour clock.
Result
- Time in London
- 2026-09-14 14:30
- Time in New York
- 2026-09-14 09:30
- Difference
- +5 hours
- Offsets
- UTC-04:00 → UTC+01:00
- In UTC
- 2026-09-14 13:30
2:30 PM GMT+1
EDT
Same calendar day
Unix timestamp 1789392600
09:30 on 2026-09-14 in New York…
target = source − source offset + target offset
New York is UTC-04:00 on this date
London is UTC+01:00
Difference of +5 hours
2026-09-14 14:30
Formula — written step by step
09:30 in New York on 15 July…
target = source − source offset + target offset
New York in July is UTC−04:00 (EDT)
London in July is UTC+01:00 (BST)
09:30 − (−4) = 13:30 UTC
13:30 + 1 = 14:30
14:30 in London
The offsets are read for the date you enter, not for today. Both cities move their clocks, but on different dates, so the gap between New York and London is five hours for most of the year and four or six for a couple of weeks each spring and autumn.
A worked example
The fortnight when the usual difference is wrong
- New York
- clocks go forward the second Sunday in March
- London
- clocks go forward the last Sunday in March
- Most of the year: London is 5 hours ahead
- Mid-March: New York springs forward first
- For those weeks the gap is 4 hours
- Late October reverses it, briefly 6 hours
Four hours, not five, for about three weeks
This is why a recurring meeting set by offset rather than by named zone drifts. Calendars that store "UTC−5" break twice a year; ones that store "America/New_York" do not. The same trap catches anyone who memorises a difference instead of checking the date.
How to use this calculator
- Set the date first — daylight saving depends on it, and the answer changes across a transition.
- Enter the time on the 24-hour clock, then pick the zone it is in.
- Choose the zone you want it in. The result shows both the 24-hour and 12-hour forms with the zone abbreviation.
- The note under the difference says whether the target lands on the same calendar day, the next or the previous.
A zone is not an offset
People treat "EST" and "UTC−5" as the same thing, but a time zone is a set of rules and an offset is a number those rules produce on a particular date. New York is UTC−5 in January and UTC−4 in July, and both are correctly called New York time.
This converter works from the date for that reason. Enter a July date and it reads the daylight-saving offset; enter a January one and it reads the standard offset. The offsets come from the system time-zone database rather than a fixed table, so they stay correct as governments change the rules — which several do every year.
Why the difference between two cities is not constant
Two zones that both observe daylight saving usually keep a steady gap, because they shift together. But they rarely shift on the same date. The United States moves in the second week of March and Europe in the last, so for about three weeks the Atlantic gap is an hour smaller than usual.
The southern hemisphere makes it worse: Sydney moves in the opposite direction to London at roughly the opposite time of year, so the difference between them swings across a four-hour range. Anyone scheduling across those zones from a memorised number will be wrong several times a year.
Storing times so they stay right
The lesson from all of this is to store an instant and a zone name, never a local time and an offset. A meeting saved as "09:00 UTC−5" is wrong from March; the same meeting saved as "09:00 America/New_York" stays right, because the rules are applied when it is read.
For anything machine-readable, store UTC and convert on display. That is what the Unix timestamp shown here is for: it names a single instant with no zone attached, which is why every system agrees on what it means.
Formula & methodology
What this calculator assumes
- Offsets come from the system IANA time zone database, so they follow daylight saving and remain correct as governments change the rules — which several do every year.
- A zone is a set of rules, not a fixed offset. New York is UTC−5 in January and UTC−4 in July, and both are correctly called New York time.
- Converting a wall-clock time iterates, because the offset depends on the instant being solved for. Times inside a spring-forward gap do not exist and times inside an autumn overlap occur twice.
Sources
Offsets, and which zones move
| Zone | Standard | Daylight saving | Observes DST |
|---|---|---|---|
| UTC | +00:00 | — | No |
| London | +00:00 | +01:00 | Yes |
| Paris / Berlin | +01:00 | +02:00 | Yes |
| New York | −05:00 | −04:00 | Yes |
| Los Angeles | −08:00 | −07:00 | Yes |
| India | +05:30 | — | No |
| Kathmandu | +05:45 | — | No |
| Tokyo | +09:00 | — | No |
| Sydney | +10:00 | +11:00 | Yes |
India and Nepal are the reminder that not every offset is a whole hour, and Nepal is the only one at forty-five minutes. Most of Asia and Africa keep one offset all year; the southern hemisphere shifts on the opposite months to the northern.
Frequently asked questions
Why does the answer change with the date?
Because most zones shift by an hour for daylight saving. The offset for New York is −5 in winter and −4 in summer, so the same wall-clock time maps to a different UTC instant depending on the date.
Which zones are not on a whole hour?
India is +5:30, Iran +3:30, parts of Australia +9:30, and Nepal is the only one at +5:45. Chatham Island in New Zealand is +12:45.
What is the difference between GMT and UTC?
For practical purposes none — both are the zero offset. UTC is the modern standard, defined by atomic clocks; GMT is a time zone that Britain uses in winter and also an older name for the same reference.
Why do my calendar invitations sometimes shift by an hour?
Usually because they were stored with a fixed offset rather than a zone name, so they did not follow the daylight-saving change. Storing the zone rather than the offset fixes it.