Time Zones Are Hard: Building a Converter with Intl.DateTimeFormat (DST Gaps, Folds and 5:45 Offsets)

Remote teams, international calls and API logs share one problem: a time that is perfectly clear in one city is ambiguous everywhere else. "Let's meet at 3 pm" is not a time until it has a zone attached.

We built a free Time Zone Converter to deal with this. You enter a date and time in any of 40 IANA time zones, and it shows the same moment in up to 8 other zones at once, each with its UTC offset and daylight-saving abbreviation. There's no server call and no sign-up. The browser's built-in Intl.DateTimeFormat does the work.

This post covers why that API is enough for most of the job, and which edge cases are worth knowing even if you never use our tool.

What Intl.DateTimeFormat gives you

Every modern browser ships with the IANA time zone database, and Intl.DateTimeFormat can format any instant in any zone from it. A minimal illustration of the idea (not our exact source):

const instant = new Date("2026-11-03T04:47:00Z"); for (const zone of ["America/New_York", "Europe/London", "Asia/Kolkata", "Asia/Tokyo"]) { const text = new Intl.DateTimeFormat("en-GB", { timeZone: zone, dateStyle: "medium", timeStyle: "short", timeZoneName: "short", }).format(instant); console.log(zone, "→", text); } 

That one formatter handles the offsets, the abbreviations and the daylight-saving rules for each zone, using the date you give it. You don't ship a time zone database and you don't hand-roll offset tables, which is the part that goes stale.

A worked example: one meeting, four cities

Say a meeting is at 14:00 UTC on a winter weekday. The equivalent local times are:

The Kolkata row is the one that surprises people. India Standard Time is a 30-minute offset, so the minutes never line up with the other rows.

Edge cases worth knowing

Offsets aren't always whole hours

Kolkata is UTC+5:30, Kathmandu is UTC+5:45, and Tehran is UTC+3:30 (UTC+4:30 in summer). Any code that stores an offset as a whole number of hours is wrong for these. Format with the IANA zone name and let the engine compute it.

Offsets depend on the date

A zone that observes daylight saving time has a different offset in July than in January. That's why the converter computes each offset for the exact date you entered, not for "now."

Daylight saving gaps and folds

This is where real bugs live.

• The gap: on the night a clock springs forward, local times between 02:00 and 03:00 don't exist in that zone.
• The fold: on the night a clock falls back, the same local time happens twice.

In the converter, the browser's IANA engine resolves a time in a gap to the post-transition equivalent rather than throwing an error. In a fold, the tool shows whichever side the engine picks, and the displayed offset tells you which one you landed on. If you build your own tool, decide up front what you want to do in these two situations, because the default behavior may not be what your users expect.

Phoenix never changes its clocks

Arizona (America/Phoenix) stays at UTC-7 all year. Los Angeles moves between UTC-8 and UTC-7, so Phoenix and Los Angeles are one hour apart in winter and on the same offset in summer. If your app hard-codes "Arizona is Mountain time," it will be off for half the year.

Using the tool

• Press Use current time to sync the input to right now, or type any past or future date.
• Change a target zone and the results update instantly.
• Each converted time has its own Copy button, so you can paste it straight into a calendar invite or a message.
• You can add up to 8 target zones. The Add button disappears at the limit; remove a row with the trash icon, or press Reset to return to the defaults (New York, London, Paris, Kolkata, Tokyo).

A limit to be aware of

Because the tool relies on the time zone data that ships with your browser and operating system, the results are only as current as that data. Abbreviations can also differ by platform. Some zones with no widely agreed short name show up as something like GMT+5:30.

Try it

Open the Time Zone Converter. If you work with dates a lot, the other Date & Time tools help too: Date Difference (exact gap in years, months and days, with leap years handled), Working Days (business days between dates, with holidays) and Date Add / Subtract (what's 90 days from today?).

What's the worst time zone bug you've shipped or debugged? I'd like to hear it in the comments.