Time Zone Converter

Tips for scheduling

Confirm both cities’ zones (e.g. America/Chicago vs America/New_York).
Watch DST transitions around spring/fall changes.
Share UTC alongside local times for global teams.

Where the time zone rules come from

This page holds no time zone data of its own. It asks your browser, which carries a copy of the IANA Time Zone Database, the dataset Linux, macOS, Android and most server software also use. That is why a conversion here agrees with a server, and why the answer can change when your browser updates: governments move their clocks and the database is revised several times a year to follow them.

Measured in a current browser: 39 zones in each dropdown and 418 in the browser's full database, any of which can be typed into the box beside the dropdown. The line under the controls reports both numbers for your own browser.

The hour that does not exist, and the hour that happens twice

Every zone that observes daylight saving has two broken hours a year, and a converter has to decide what to do with them. This one decides silently.

The missing hour. On 8 March 2026 the clocks in New York jump from 01:59 to 03:00, so 02:30 never happens. Ask for it anyway and you get an answer: the tool moves it forward by an hour and converts 03:30 instead. Measured, 2026-03-08T02:30 in America/New_York comes back as 07:30 UTC, and the “From” row underneath reads 03:30, not the 02:30 you typed. The tool does show you the substituted time, in that one row, but it never says it made a substitution. The consequence to watch for is that 02:00 and 03:00 both convert to 07:00 UTC, so two different inputs give one instant.

The repeated hour. On 1 November 2026 the clocks go back, so 01:30 in New York happens twice, once at 05:30 UTC and again an hour later at 06:30 UTC. This tool always gives you the first. Measured across 01:00, 01:15, 01:30, 01:45 and 01:59, every one resolves to the earlier, daylight-saving occurrence, and the second pass through that hour cannot be expressed on this page at all. There is no switch for it. If you are scheduling something inside the repeated hour, or reading a log that falls in it, convert from UTC instead, which is never ambiguous.

EST is not New York, and it is the easiest mistake to make here

The box beside the dropdown accepts anything your browser recognises, which is more than the proper city names. Three of those extras are worth knowing before you rely on them.

EST is a fixed offset with no daylight saving. Measured on 15 June 2026 at 09:00, a conversion from EST gives 14:00 UTC and the same wall time from America/New_York gives 13:00 UTC. For most of the year those two differ by an hour, and the tool accepts both without comment. If you mean the place, name the place.
Etc/GMT+5 is five hours behind UTC, not ahead. The sign in those names is inverted by an old convention that the database keeps for compatibility. Measured, it agrees with EST at 14:00 UTC, which is the opposite of what the name suggests.
Old names still work. US/Eastern is kept as a link to America/New_York and gives the identical answer, 13:00 UTC. So does lower case: america/new_york is accepted, because zone names are matched without regard to case.

A name your browser does not recognise is refused outright rather than guessed at. Typing Mars/Olympus produces “Invalid from time zone” and no conversion.

Three details in the controls that are easy to miss

The typed box beats the dropdown, silently. If there is any text in the box beside a dropdown, that text is used and the dropdown is ignored, while the dropdown carries on displaying something else. Measured: with the dropdown reading America/New_York and the box reading Asia/Tokyo, the conversion ran from Tokyo and the result row said so. Clear the box to go back to using the dropdown.

“ISO-like” means like ISO, not ISO. That format prints 2026-06-15T22:00:00 with no trailing Z and no +09:00. RFC 3339, the internet profile of ISO 8601, requires an offset precisely so a timestamp names one moment. Without it the text is a wall-clock reading any system is free to interpret in its own zone: convenient to read, poor to paste into a database, a config file or an API. The UTC row underneath does end in Z and is the one safe to copy.

Seconds work but are not offered. The control steps in whole minutes, so the picker cannot set seconds, yet a value containing them is honoured: a time ending :45 comes through as :45, and the Unix timestamp reflects it.

Odd offsets and old dates both work

Zones that are not a whole number of hours from UTC are handled properly, which is not true of every converter. Measured against 12:00 UTC on 15 June 2026: Asia/Kolkata gives 17:30 at +5:30, Asia/Kathmandu gives 17:45 at +5:45, and Pacific/Chatham gives 00:45 the next day at +12:45.

Historical dates use the rules in force at the time. Measured, 15 June 1920 in New York converts four hours behind UTC, daylight saving having been in effect, and 1 January 1970 converts five hours behind. The future is weaker: 2099 is converted with today's daylight saving rules projected forward, and no database can know whether they will still exist.

What this tool deliberately does not do

It does not warn you about the two broken hours. A time in the missing hour is moved forward without comment, and a time in the repeated hour always resolves to the first occurrence.
It cannot express the second pass of the repeated hour, in any zone, by any input.
It does not convert a range or a list, and it does not find a meeting slot. It converts one instant you already chose; it will not tell you which hour suits three cities.
It does not output an offset in ISO-like mode, so that text does not identify a unique moment.
It carries no zone data of its own, so a stale browser gives stale answers for any country that recently changed its rules.
Nothing is uploaded. The conversion happens in your browser and no date, time or zone leaves your device.

If you want the Unix timestamp on its own, or to read one back, Unix Timestamp Converter does that directly. For the number of days between two dates rather than a conversion, use Days Between Dates.

Sources

The zone rules themselves, and how often they change: IANA Time Zone Database. iana.org/time-zones
The list of zones the browser exposes, which is where the 418 figure comes from: Intl.supportedValuesOf. developer.mozilla.org
Why a timestamp without an offset does not name a moment: RFC 3339, Date and Time on the Internet: Timestamps. rfc-editor.org/rfc/rfc3339
Why the date and time control offers no seconds: the datetime-local input steps in minutes unless told otherwise. developer.mozilla.org

Every behaviour and every value on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Zone counts and historical offsets come from the database in that browser and may differ slightly in yours.

Frequently asked questions

Does it handle daylight saving?

Yes, through the IANA database in your browser, and it gets ordinary and historical dates right. The two hours a year where daylight saving breaks are handled silently rather than correctly: read the next two answers before trusting a conversion inside them.

What happens if I enter a time that does not exist?

You still get an answer. On 8 March 2026 the clocks in New York skip from 01:59 to 03:00, and asking for 02:30 converts 03:30 instead, with the “From” row quietly showing 03:30. Nothing says a substitution happened, and 02:00 and 03:00 both come out as 07:00 UTC.

What about the hour that happens twice in autumn?

You always get the first of the two. On 1 November 2026, 01:30 in New York exists at both 05:30 and 06:30 UTC, and every input in that hour resolves to the earlier one. The later occurrence cannot be reached from this page at all, so for anything inside the repeated hour work from UTC instead.

Can I just type EST instead of America/New_York?

You can, and for most of the year you will get the wrong answer. EST is a fixed offset that never observes daylight saving, so on 15 June 2026 a 09:00 reading gives 14:00 UTC from EST and 13:00 UTC from America/New_York. Name the city, not the abbreviation. The old name US/Eastern is safe, as it is simply a link to America/New_York.

Why does Etc/GMT+5 behave like minus five?

Because the sign in those names is inverted, a convention inherited from POSIX that the database keeps for compatibility. Etc/GMT+5 is five hours behind UTC. It is a good reason to use city names, where the sign is not a trap.

Can I paste the ISO-like output into other software?

Better not. That format has no offset and no trailing Z, so it names a wall-clock reading rather than a moment, and anything reading it will apply its own zone. RFC 3339 requires the offset for exactly this reason. Copy the UTC row instead, which ends in Z and is unambiguous.

I changed the dropdown and nothing happened.

There is probably text in the box next to it. Anything typed in that box takes priority and the dropdown is ignored, while still displaying its own value. Clear the box and the dropdown takes effect again.

Are half-hour zones like India and Nepal correct?

Yes. Measured against 12:00 UTC, Asia/Kolkata gives 17:30, Asia/Kathmandu gives 17:45, and the Chatham Islands give 00:45 the next day at a 12 hour 45 minute offset.