Time zones β the hour that does not exist, and the one that happens twice
What time is 3pm in Seoul, in New York? It looks like adding and subtracting, except the difference is not a fixed number and some times of day do not exist at all. That is usually where an hour goes missing from a meeting invitation.
Everyone knows regions are hours apart. The complication is that the gap changes with the season: much of North America and Europe moves clocks forward in spring and back in autumn. So βNew York is fourteen hours behindβ is true for about half the year.
This tool uses the browser's own calculation, which is backed by the IANA time zone database. That database carries each country's rules and its history of changes, which is why it beats a table of offsets written down by hand.
The hour the clock skips does not exist
On the morning daylight saving starts, New York's clock goes straight from 2am to 3am. There is no 2:30 that day. Most converters answer anyway β some say 3:30, some say 1:30 β without mentioning that the question had no answer.
Going the other way, an hour repeats. New York's 1:30am on 1 November happens twice, and the two are separate moments an hour apart. If a flight or a meeting falls there, somebody has to decide which one is meant.
This tool tells you which of the two situations you are in rather than quietly picking. Only a person knows which was intended.
Boundaries, checked
For 2026. Korea has no daylight saving, so it never hits either case.
| Zone | Local time | What happens |
|---|---|---|
| New York | 8 Mar, 02:30 | does not exist (2am jumps to 3am) |
| New York | 1 Nov, 01:30 | happens twice |
| London | 29 Mar, 01:30 | does not exist |
| London | 25 Oct, 01:30 | happens twice |
| Adelaide | 5 Apr, 02:30 | happens twice |
| Seoul | 1 Jul, 02:30 | ordinary |
Offsets are not always whole hours
Thinking in whole hours gets several places wrong. India is on a half hour, Nepal on a quarter. Choosing a zone by name rather than by offset makes those correct without any special handling.
Offsets that are not whole hours
| Place | Offset |
|---|---|
| Seoul, Tokyo | UTC+9 |
| India (Kolkata) | UTC+5:30 |
| Nepal (Kathmandu) | UTC+5:45 |
| Iran (Tehran) | UTC+3:30 |
| Adelaide | UTC+9:30 |
| Chatham Islands | UTC+12:45 |
History matters for old dates
Korea's last period of daylight saving was 1988, around the Seoul Olympics: UTC+10 that summer and UTC+9 in winter. Converting a date from that year, this tool applies the rule that was in force then.
A converter with today's offsets hard-coded is an hour out on any date before a country last changed its rules β which is most countries at some point.
Scheduling across zones
- β’If the date is near a transition, fix the date before agreeing the time. The first weeks of March and November are the risky ones in the northern hemisphere.
- β’The southern hemisphere moves the other way β Australia and New Zealand shift clocks during the northern autumn.
- β’Write the zone in the invitation. β3pm KSTβ lets the reader convert; β3pmβ does not.
- β’UTC avoids the problem entirely, at the cost of most people not knowing what time UTC is.
Frequently asked questions
Why not use abbreviations like EST or CST?
They collide. CST is both US Central and China Standard Time. A zone name like Asia/Seoul is unambiguous and carries the daylight saving rules with it.
How are the rules kept up to date?
They come from the browser and operating system, which update when a country changes its rules. This tool holds no table of its own, so there is nothing here to go stale.
What happens if I enter a time that does not exist?
You are told that it does not, rather than given an invented answer. Usually the hour before or after was meant.
Is anything I enter stored?
No. The conversion runs in your browser.