Convert a time between zones — and find out if it exists
Timezone conversion looks like addition and is not. On the day the clocks change, an hour of local time does not exist and another happens twice. This says so instead of returning a plausible answer to an impossible question.
02:30 does not exist in America/New_York on that date — the clocks skipped it.
There is no instant in time that matches this local time.
What to watch for
This will bite you
That local time never happens
02:30 on 2026-03-08 does not exist in America/New_York. Daylight saving moved the clock forward across it, so there is no instant in time whose wall clock in America/New_York reads that. Anything scheduled for it either does not fire or fires at a time nobody chose.
Fix: Pick a time outside the skipped window — usually an hour later is what was meant — or store the event as a UTC instant rather than a local wall-clock time.
Note
UTC does not observe daylight saving
UTC keeps the same offset all year, so its clocks never change. If the other zone does observe it, the gap between them shifts twice a year even though nothing changes on this side.
Upcoming clock changes
America/New_York
2026-03-08T07:00:28.125Z
Clocks jump forward an hour: 03:00 is followed by 03:00, and the times in between never happen.
UTC−05:00 → UTC−04:00 (EST → EDT)
2026-11-01T06:00:00.000Z
Clocks fall back an hour: the wall clock returns to 01:00, so that hour happens twice.
UTC−04:00 → UTC−05:00 (EDT → EST)
UTC
No clock changes — this zone keeps one offset all year.
Worked examples
- The local time that does not exist
- The local time that happens twice
- New York to India
- Los Angeles to London
- New York to Tokyo
- London to Sydney
- Why India is half an hour off
- The 45-minute offset
- Arizona does not change its clocks
- When do the clocks change next?
- Scheduling a meeting across three zones
- UTC to local time
- Brazil abolished daylight saving
- Why writing "BST" is dangerous
Built for agents too
Worth calling rather than computing: a skipped or repeated local time produces a confident wrong answer, and nothing in that answer reveals the problem.
curl 'https://timezone-truth.gumballtools.com/api/v1/convert?time=2026-03-08%2002:30&from=America/New_York&to=UTC'Questions people actually ask
Can a local time really not exist?
Yes, and it is the most common timezone bug there is. When clocks jump forward an hour, that hour of wall-clock time is skipped: in New York on 8 March 2026, the minute after 01:59 is 03:00, so 02:30 never happens. Nothing has that wall clock, so there is no instant to convert it to. A job scheduled for 02:30 local either does not run or runs at whatever time the scheduler decides to substitute.
What happens to a time that occurs twice?
When clocks go back, an hour repeats — 01:30 on 1 November 2026 in New York happens once at 05:30 UTC and again at 06:30 UTC. Both are correct. Almost every date library returns a single instant for that local time, and which one it picks is rarely documented. This tool returns both and asks you to say which you meant.
Why is writing "BST" or "CST" dangerous?
Because those abbreviations are not unique, and most runtimes accept them anyway. Node resolves BST to Bangladesh Standard Time, UTC+06:00 — while almost everyone who writes BST means British Summer Time, UTC+01:00. That is a five-hour error that produces a completely plausible timestamp with no warning. CST is US Central or China Standard Time depending on who is asking; IST is India, Israel, or Ireland. This tool rejects them all and tells you what your runtime would have silently assumed.
Is the difference between two zones constant?
No, and assuming it is causes a predictable bug twice a year. Zones start and end daylight saving on different dates: the US changes in March and November, the EU in March and October, and Australia in the opposite direction. For a few weeks each year London and New York are four hours apart instead of five. Never cache an offset between two zones — recompute it for the specific date.
Are all timezone offsets whole hours?
No. India is UTC+05:30, Nepal is UTC+05:45, and parts of Australia are UTC+08:45. Newfoundland is UTC−03:30. Any code that stores an offset as an integer number of hours is wrong for hundreds of millions of people.
Why does this refuse to parse "next Tuesday at 3pm"?
Because interpreting it requires guessing — whose Tuesday, in which zone, and 3pm where. A wrong answer here is indistinguishable from a right one, so the tool asks for an unambiguous YYYY-MM-DD HH:MM instead. That refusal is the feature: everything this tool returns is something it can be certain about.
Where does the timezone data come from?
The IANA database shipped with the runtime, read through the standard Intl APIs. Transitions are found by searching for offset changes rather than from a hardcoded table, so the answers stay correct as the data is updated. Timezone rules are political and change with little notice — Brazil abolished daylight saving in 2019 and broke a lot of hardcoded logic.
How should I store times to avoid all this?
Store the UTC instant, plus the IANA zone name if you need to show or recompute local time later. Never store a local wall-clock time as your source of truth for anything in the future: the rules for converting it can change between now and then, and if it falls in a skipped or repeated hour it is not a well-defined moment at all.
Can an AI agent call this directly?
Yes, and it should. There is a JSON API at /api/v1/convert, an MCP server at /api/mcp exposing a convert_time tool, an OpenAPI document at /.well-known/openapi.json, and a machine-readable index at /llms.txt. Every page is also available as markdown at the same URL with an Accept: text/markdown header.