Time zone converter

How one instant becomes many local times

An instant is a single number: the count of seconds or milliseconds since midnight UTC on 1 January 1970. It has no zone, no calendar and no clock reading built into it. Everything in the table below the input is a rendering of that one number, produced by asking the IANA time zone database what a particular region's clocks were showing at that moment. Change the zone and the number does not move; only the description of it does.

The offset for each row is read out of the platform's own zone data rather than calculated, because offsets are political rather than geometric. A zone's distance from UTC is set by legislation, it changes when a government decides it changes, and the history is full of one-off moves — Samoa skipping 30 December 2011 entirely, Turkey abandoning winter time in 2016, Kazakhstan collapsing two zones into one in 2024. Each row asks Intl.DateTimeFormat with timeZoneName: 'longOffset' for the offset that applied at that specific instant, which means a timestamp from last March gets last March's rules, not today's.

The input accepts four shapes. A run of digits is treated as an epoch value, seconds below eleven digits and milliseconds at eleven or more, and the line under the box states which reading it used so the assumption is never silent. An ISO 8601 string carrying its own Z or ±HH:MM is absolute, so the source-zone select is ignored for it. A bare YYYY-MM-DD HH:MM has no offset in it and is therefore meaningless until you say where it was written, which is what the source zone is for. The Now button just drops in the current epoch second.

Reading the daylight saving column

No browser API answers the question "is summer time in effect here" directly, so the column is derived. The rule used is the one that holds worldwide: a zone's standard time is the smaller of the two offsets it uses in January and July of the same year, and any offset above that minimum is a daylight saving shift. That gets the southern hemisphere right without a special case — Sydney's January offset of UTC+11:00 is the larger of its two, so January is correctly the summer one, and July's UTC+10:00 is standard.

Zones that have never observed summer time, or that abandoned it, report the same offset in both months and so always read as No. That covers most of Asia, all of Russia since 2014, Arizona, Iceland and a growing list of others. The column is about the instant in the box, not about today, which matters more than it sounds: a log line from July looks at July's rules even if you are reading it in December.

Abbreviations deserve a warning. They come from CLDR, they are not unique, and they are not available for every zone in every locale — IST alone means Irish Standard Time, India Standard Time and Israel Standard Time depending on who is speaking. Where no abbreviation exists the table falls back to a numeric form such as GMT+5:30. Treat the offset column as the authoritative one and the abbreviation as a hint.

Questions people ask

Why does a meeting time land on a different date for some people?

Because the date is part of the local rendering, not part of the instant. A call at 20:00 UTC on a Thursday is 05:00 on Friday in Tokyo and 15:00 on Thursday in New York, and everyone involved is correct. The gap is widest across the Pacific: Auckland and Honolulu can sit on different calendar days for most of the working day. This is the single most common source of an off-by-one-day bug in scheduling code, and the fix is always the same — store the instant, render the date at the last possible moment, and never send a bare date across a zone boundary without saying which zone it belongs to.

What is the difference between a time zone and a UTC offset?

An offset is a number, such as +02:00. A zone is a rule set with a name, such as Europe/Berlin, that says which offset applies on which dates, going back decades and forward as far as the law is known. Berlin is +01:00 in winter and +02:00 in summer, so the offset alone tells you nothing about which zone you are in — Johannesburg is also +02:00, permanently. Offsets describe a moment; zones describe a place over time. That is why the table shows both, and why the two columns are not redundant.

Should I store a zone name or an offset in the database?

For an event that already happened, store the instant — an epoch value or a UTC timestamp — because the offset is only needed to display it and can be recomputed at any time. For an event in the future, store the IANA zone name alongside the local time the user picked. A recurring 09:00 stand-up in Europe/London must stay at 09:00 through the March and October transitions, and it will only do that if the zone rules are applied at render time. Storing +00:00 with it freezes the wrong half of the information, and the meeting drifts by an hour twice a year.

What happens to a local time that falls inside a daylight saving change?

Two awkward things, in opposite directions. When the clocks jump forward, an hour of local time never occurs: 01:30 on 29 March 2026 simply does not exist in Europe/London, and this page says so rather than pretending, then shows the instant immediately after the jump. When the clocks fall back, an hour repeats, so 01:30 on the last Sunday of October happens twice and a bare local time is genuinely ambiguous. Any system that accepts wall-clock input has to make a decision about both cases; most libraries default to the earlier of the two repeats and reject or shift the missing one.

Why does the abbreviation say GMT+5:30 instead of IST?

Because the browser's locale data has no abbreviation for that zone in the locale being asked. CLDR only carries short names where a region actually has one in common use, and it carries them per language, so a page asking in American English gets EDT for New York but a numeric form for London, while asking in British English gets BST for London and a numeric form for New York. This page tries both before falling back, which covers the zones people usually compare. When nothing matches, the numeric form is the honest answer — and it is also the unambiguous one.