Time Zone Converter

Convert a date and time between time zones with automatic daylight-saving handling, including the dates when the rules change and disagree.

Twice a year, an hour does not exist

Converting between zones feels like arithmetic on offsets, and twice a year it is not, because the offset moves underneath you. In New York on 8 March 2026 the clock goes from 01:59 straight to 03:00. Probing the actual local reading either side of the jump gives these hours:

00 01 03 04

02 is missing. The hour beginning 02:00 is simply absent from that day, so a meeting scheduled for 02:30 has no moment at which to happen. A converter that does not account for it will quietly return 03:30, or 01:30, or throw — and which one you get is a property of the library rather than of the question.

On 1 November the opposite occurs. These local readings each happen twice, an hour apart:

01:00 01:15 01:30 01:45

"01:30 on 1 November" names two distinct instants, and no amount of extra precision in the local time separates them. Notice that these are opposite failures rather than the same bug twice: going forward, labels are skipped and no instant is lost; going back, instants are duplicated and no label is lost. Code that handles one often mishandles the other.

And not every offset is a whole number of hours

The other assumption worth discarding is that zones differ by whole hours. Asking the browser's own zone database how many distinct non-whole-hour offsets are currently in use:

OffsetZonesFor example
-09:30 1 Pacific/Marquesas
-03:30 1 America/St_Johns
+03:30 1 Asia/Tehran
+04:30 1 Asia/Kabul
+05:30 2 Asia/Calcutta, Asia/Colombo
+05:45 1 Asia/Katmandu
+06:30 2 Asia/Rangoon, Indian/Cocos
+08:45 1 Australia/Eucla
+09:30 1 Australia/Darwin
+10:30 2 Australia/Adelaide, Australia/Broken_Hill
+13:45 1 Pacific/Chatham

11 distinct offsets across 14 zones — and the bold rows are not even half-hours. Nepal sits at +05:45, Australia's Eucla at +08:45 and the Chatham Islands at +13:45. Any code that stores an offset as a whole number of hours is wrong for well over a billion people, and the failure is invisible from most of the world.

All of which points at one habit worth adopting: store the instant — a UTC timestamp — and the zone name separately, and resolve the local reading only when you display it. Storing a local time plus an offset looks equivalent and is not, because the offset is a property of a moment rather than of a place. The same city has two different offsets depending on the date, and which one applies is exactly the question a stored offset has already thrown away.

How to use

  1. Enter the date and time, and its zone.
  2. Choose the zone you want it converted to.
  3. Read the converted time and the offset.
  4. Check the date if the conversion crosses midnight.

Frequently asked questions

Why is a time zone not simply an offset?

Because the offset changes through the year. A zone is a set of rules — an offset plus when daylight saving starts and ends — and those rules have changed repeatedly through history. Storing an offset rather than a zone means a future date will be wrong once the rules shift.

Why do the US and Europe change clocks on different dates?

Because each legislates independently. The US moves in mid-March and early November; the EU moves on the last Sundays of March and October. For a few weeks each year the usual difference between, say, London and New York is an hour out from what everyone expects, which is a reliable source of missed meetings.

What is UTC and how does it differ from GMT?

UTC is the modern time standard, maintained by atomic clocks and adjusted with leap seconds. GMT is a time zone that happens to equal UTC in winter and shifts to British Summer Time in the UK's summer. They are used interchangeably in casual speech and are not the same thing.

Do all time zones differ by whole hours?

No. India is 5 hours 30 minutes ahead of UTC, Nepal 5 hours 45, and several others use half-hour offsets. Assuming whole hours is a common bug in software that handles scheduling.

What happens to times that do not exist?

When clocks spring forward, an hour is skipped entirely, so a time in that gap never occurs. When clocks fall back, an hour repeats and a time occurs twice. Both cases have to be handled deliberately — this is where scheduling software most often goes wrong.

How should I store times in a database?

In UTC, with the original zone recorded separately if it matters. UTC is unambiguous and never shifts, so arithmetic on it is reliable. Converting to local time is a display concern, and doing it at display time rather than at storage avoids an entire category of bug.

🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.