🌐 Timezone Converter

By Λ · Updated June 9, 2026 · ~3 min read

Why I built another timezone converter

Every existing timezone converter I tried either uses UTC offsets (which are wrong half the year because of DST), refuses to handle the IANA names I actually have in my code (America/Los_Angeles, not "PST"), or shoves city pictures and ads in front of the conversion. So I built this one. It uses your browser's built-in Intl.DateTimeFormat API to do the actual conversion, which means it follows the same tz database (tzdata) that Node, Python, and most servers use.

How to use it

Pick a date and time, pick the source timezone (the one those numbers refer to), and the page will display the equivalent moment in every zone you have added to the list. The default zones are your local browser timezone plus UTC plus a few common ones. Add or remove any IANA zone using the picker below the list.

Under the hood

Convert finds the real UTC instant whose wall-clock reading in the source zone matches what you typed (probing via formatToParts), then formats that instant into every zone on your list. The offset label under each name is computed for the same instant, so it flips automatically when a zone crosses a DST boundary. The picker comes from Intl.supportedValuesOf, the browser's full IANA list, and your curated zones persist in localStorage. Nothing calls a time server: the math runs against the tzdata bundled with your browser, so the times you enter stay inside this page.

Worked examples

Enter 2026-07-15T09:00 from America/Los_Angeles: the list shows 16:00 UTC, 12:00 New York, 17:00 London, and 01:00 Thursday in Tokyo, the overnight rollover that trips up call scheduling with Japan. Try 2026-10-28T09:00 from America/New_York: London reads 13:00, four hours ahead instead of five, because Europe fell back on October 25, 2026 while the US holds DST until November 1.

Limits worth knowing

The datetime field has minute precision; seconds are always :00. A time inside a spring-forward gap (a 02:30 that never happened) still returns a result, silently nudged onto a real instant. Tz rule changes only arrive with browser updates, so a freshly rewritten national DST law may convert against stale rules for a while.

DST handling, the part most converters get wrong

Daylight Saving Time changes the UTC offset for a given zone twice a year, on different dates per country. Most converters that show "PDT" or "GMT+8" hardcode the offset and silently break twice a year. This tool uses the IANA name and lets the browser's tz database resolve the offset for the specific instant you picked, which is the only correct way to do this.

For scheduling meetings

If you are scheduling a meeting across zones, the trick I use: pick the source timezone of whoever is the meeting-anchor (usually the most-senior person or the customer), set the time to whatever works for them, then read off all the other zones. Anyone who is asleep at that hour either declines or asks for a reschedule.

For calendar invites

If you are programmatically generating ICS calendar files, store all events in UTC and let the receiving client convert. Do not store events in "America/Los_Angeles 09:00" because LA changes its offset twice a year and your event will silently drift one hour. UTC plus a stored IANA name for display is the canonical pattern.

Frequently Asked Questions

Why is my zone list missing on another device?

It lives in this browser's localStorage and never syncs. Clearing site data restores the six default zones.

Can I pick PST, CET, or IST instead of IANA names?

No. Abbreviations are ambiguous (IST can mean India, Israel, or Ireland), so the picker only lists unambiguous zone names.

What does the GMT-07:00 label actually show?

That zone's UTC offset at the instant you converted, not a fixed property. A January conversion shows the Los Angeles row as GMT-08:00.

Related

For day-counting math, see the date difference calculator. For Unix timestamp parsing, see the timestamp converter.