Time Zone Converter

A time zone is a rule, not an offset

It is tempting to think of a zone as a number of hours from UTC, and that works until it does not. Europe/London is UTC in January and UTC+1 in July; America/New_York is -5 then -4; Australia/Sydney is +11 then +10, in the opposite order, because summer is in December there. The offset is what the rule says on a particular date, not a property of the place.

That is why this page reads the offset at the instant being converted, rather than storing one number per zone. A zone name such as Asia/Kolkata or America/Sao_Paulo carries the whole history of what that region has done with its clocks since 1970, and the database knows about every change.

Some offsets are not whole hours. India is +5:30, Nepal +5:45, parts of Australia +9:30, Newfoundland -3:30, and the Chatham Islands +12:45. The page computes offsets in minutes rather than hours so none of those get rounded away.

Where the numbers come from, and how they can be wrong

There is no time zone table in this page’s code. The offsets are read from the browser’s own copy of the IANA database through the built-in internationalisation API, which cannot report an offset directly - so the page formats the instant in the target zone, reads the wall-clock digits back, and compares them with the same digits interpreted as UTC. The difference is the offset.

The consequence is worth being blunt about: if a government changes its rules and your browser’s database has not been updated, this page will be wrong in the same way your computer’s clock would be. The database is normally updated with the browser or the operating system, and countries usually announce changes months ahead, but a rule changed last week may not be in there yet.

The same database decides what the zone is called: GMT, BST, CET, IST, JST and so on, as the platform spells them. Abbreviations are not unique - IST is India, Ireland and Israel - which is why the page offers both the name and the offset, and why the zone list uses IANA names rather than abbreviations.

The hour that happens twice, and the hour that never happens

When a zone leaves daylight saving in the autumn, the local clock goes back an hour, so the hour between 01:00 and 02:00 happens twice; a wall-clock time in that hour is genuinely ambiguous, and the page will pick the first by its iteration rather than claiming certainty. In the spring the clock jumps forward, and the hour between 02:00 and 03:00 does not happen at all: a time in that hour never existed locally.

That is not a defect of this page, it is a property of local time. Anybody scheduling inside those hours is better served by agreeing the instant in UTC and letting each side convert it. The page prints the UTC equivalent of everything it shows for exactly this reason.

What this page does not do

It does not convert a meeting series, keep a calendar, or handle "the second Tuesday of every month at 10:00 local" - that needs a zone-aware calendar, because recurring meetings across zones drift by an hour when only one side changes its clocks. The page shows the reason that drift happens; it does not solve it.

It does not know about time zone boundaries inside countries either. The database knows that a zone exists, not which county you are in: some countries span several zones, and some have regions that opted out of daylight saving while the rest did not. The zone you choose is the zone you get.