Time Zone Converter
Pick a source zone, pick a date and time, then add as many target zones as you need. Each target shows the local day-of-week, date, time and UTC offset. The browser handles DST through the IANA tzdata, so the answer is right whether you ask in summer, winter or on the day the clocks change.
Explain like I'm 5 (what even is this calculator?)
Different parts of the world set their clocks differently. If a meeting is at 3pm in London, that's 10am in New York and 11pm in Tokyo. This tool does that maths for any date, any time and any number of cities. It also gets daylight saving right, so the answer is correct in both halves of the year.
Convert a moment between zones
Browser-only. The conversion uses your browser's built-in Intl API. Nothing you enter is sent anywhere.
Target zones
Prove it
The conversion uses your browser's Intl API, which reads IANA time-zone definitions from the OS-supplied tzdata. The same database powers Linux servers, macOS, Windows and every modern phone. Daylight-saving rules, historical offset changes and oddities like Nepal's UTC+5:45 are all baked in.
The conversion is anchored on a single UTC instant, derived from your wall-clock input in the source zone:
UTC anchor: —
From that instant, each target zone is rendered with Intl.DateTimeFormat. The offset for each row (UTC+1, UTC-5, UTC+5:30) is computed by formatting the same UTC instant in that zone and comparing the wall-clock that comes back to the original UTC time. No hand-rolled offset table exists in this code. If your machine's tzdata is current, the answer is correct.
To check it yourself: open the browser console and run Intl.DateTimeFormat('en-GB', { timeZone: 'America/New_York', hour: '2-digit', minute: '2-digit', hourCycle: 'h23' }).format(new Date('—')). The output should match the New York row above.
Useful? Save this calculator: press Ctrl + D to bookmark it.
When to use a time zone converter
Three situations cover almost everything. The first is scheduling: working out a meeting time that lands inside business hours in three different countries. The second is remembering: looking back at a log line stamped in UTC and asking what time that actually was where the user was sitting. The third is travelling: knowing what time a flight lands in the destination zone, not the time the boarding pass shows in the departure zone.
The common thread is that you need both ends of the conversion to be honest about which zone you mean. "3pm UK time" sounds clear and is not, because UK time is GMT in winter and BST in summer. The only way to be right year-round is to pick the IANA name (Europe/London) and let the tzdata work out which offset applies on the date you care about.
Common mistakes
Treating short codes as zone names. EST, CST, PST, GMT, BST: these are offset labels, not zones. They tell you what offset is in force at one moment, not which offset will be in force tomorrow. Use the IANA name for the zone (America/New_York, not "EST").
Forgetting that the date can roll over. Tuesday 23:00 in London is Wednesday 11:00 in Auckland on most dates of the year. The day-of-week label on each target row is there precisely so you don't book a meeting for the wrong day. Watch for it on calls between Europe and the Pacific, and between the Americas and Asia.
Assuming the offset is constant. Most zones change offset twice a year, on dates that differ by country. The UK and EU shift on the same Sunday in March and October; the US and Canada use a different Sunday; Australia and New Zealand are the opposite way round because their seasons are inverted. If you build a recurring meeting in March, half the participants will be an hour off for two weeks until the other half also switch.
Edge cases worth knowing about
Half-hour and quarter-hour zones. India is UTC+5:30, Iran is UTC+3:30, Newfoundland is UTC-3:30, Nepal is UTC+5:45, the Chatham Islands are UTC+12:45. Software that hard-codes whole-hour offsets gets these wrong. The Intl API does not.
The non-existent hour and the doubled hour. On the spring-forward Sunday, the wall clock skips an hour. 02:30 simply does not happen in the UK on that day. On the autumn fall-back Sunday, the hour 01:00-02:00 happens twice. The converter resolves both cases to a stable answer rather than refusing to compute, but if it really matters (logging an exact medical event, say), think carefully about which side of the boundary you mean.
Zones that don't observe DST. Most of Arizona stays on Mountain Standard Time year-round, while the rest of the US Mountain time zone goes onto MDT in summer. So Phoenix and Denver are an hour apart for half the year and the same for the other half. Use America/Phoenix for the no-DST cases.
Related calculators
Time zones are one piece of meeting logistics. These cover the rest.
Frequently asked questions
How does this handle daylight saving time?
It does not handle DST at all. The browser does, by reading the IANA tzdata that ships with your operating system. We hand the wall-clock time and the source zone to Intl.DateTimeFormat, which knows when each zone springs forward and falls back. As long as your OS has a recent tzdata (any system updated in the last few months will), the result is correct on the day of the change too.
What's an IANA time zone?
IANA names are the canonical way to identify a time zone, written as Region/City. Europe/London, America/New_York, Asia/Tokyo, Pacific/Auckland. They beat short names like "BST" or "EST" because those are ambiguous (BST is also Bangladesh Standard Time, EST is also Australian Eastern Standard Time) and because the IANA name carries the full DST history with it. The dropdown lists about 60 of the most-used ones; the free-text option accepts any valid IANA name.
What happens at the moment the clocks change?
If you enter a wall-clock time that does not exist (in the UK, 02:30 on the spring-forward Sunday simply does not happen, because the clock jumps from 01:00 to 02:00), the converter resolves to a stable, deterministic instant rather than throwing. If you enter a wall-clock time that happens twice (the autumn fall-back hour, 01:30 happens once in BST then again in GMT), it picks one consistently. Both edge cases are rare in practice, but they exist.
Why not just show UTC offsets?
Offsets are useful for spotting differences at a glance, so each row shows one (UTC+1, UTC-5, UTC+5:30 and so on). But the offset for a given zone changes through the year, sometimes twice. "Europe/London is UTC+0" is true in winter and false in summer. Working with IANA names rather than fixed offsets is the only way to be right all year round.