Time Zone Converter Online — Free IANA Time Zone Tool

Convert any datetime across 400+ IANA time zones with full DST handling. Side-by-side cards for UTC, EST, PST, IST, JST or any zone you add. 100% browser, powered by Intl.DateTimeFormat.

Source datetime

Source zone

Add target zone6 target zones

UTC

Set source datetime above.

America/New_York

Set source datetime above.

America/Los_Angeles

Set source datetime above.

Europe/London

Set source datetime above.

Asia/Kolkata

Set source datetime above.

Asia/Tokyo

Set source datetime above.

What is a Time Zone Converter?

A time zone converter takes a single moment in time and shows what clock-time that same moment is in any other zone — accounting for the moving target of daylight saving rules. Pick a meeting time in New York and instantly see what that is in London, Mumbai, Singapore, and Sydney.

The OpenFormatter converter uses Intl.DateTimeFormat with IANA zone identifiers (America/New_York, Asia/Kolkata) so the output is always DST-correct for the date you pick. Add as many target zones as you want, see the live UTC offset and DST status on each card, and never run another "wait, are they on summer time yet?" mental calculation.

How to convert time zones online — 4 steps

Set your source datetime and zone. Enter a date and time and pick the IANA zone it is given in. Click Now to fill with the current moment in your browser's zone.
Pick target zones. Six common zones load by default. Add any IANA zone from the picker; remove any with the close button.
Read the cards. Each card shows the same instant in its zone — date, day of week, 24-hour time, live UTC offset, and DST status.
Share or schedule. Use the cards to confirm a meeting time, debug a log timestamp, or verify a cron schedule fires at the same instant everywhere.

Sample input and output

Source:  2026-07-15 14:00  in America/New_York

UTC                  Wed, July 15, 2026   18:00:00   UTC+0
America/New_York     Wed, July 15, 2026   14:00:00   UTC-4   (DST active)
America/Los_Angeles  Wed, July 15, 2026   11:00:00   UTC-7   (DST active)
Europe/London        Wed, July 15, 2026   19:00:00   UTC+1   (DST active)
Asia/Kolkata         Wed, July 15, 2026   23:30:00   UTC+5:30
Asia/Tokyo           Thu, July 16, 2026   03:00:00   UTC+9   (no DST)

400+ IANA Zones

Use the canonical Olson identifiers (America/New_York, Asia/Kolkata) — every zone the browser ships in its IANA snapshot is supported.

DST-Aware

Built on Intl.DateTimeFormat which knows every historical and upcoming DST transition. The card shows the exact UTC offset for the date you pick.

Side-by-Side Cards

Add any number of zones; each card renders date, weekday, time, offset, and DST status. Perfect for global standup scheduling.

Common use cases

check_circleScheduling a meeting across distributed teams (US, EU, India, APAC) in one screen
check_circleConfirming a UTC log timestamp in your local clock during incident response
check_circleTranslating a deploy window from PST to GMT for a European on-call rotation
check_circleSanity-checking that a UTC cron schedule fires at the right local hour
check_circlePicking a webinar time that works in three regions
check_circleDebugging DST-edge bugs by jumping to the day before/after a transition
check_circleTranslating support-ticket SLAs given in customer-local time to UTC
check_circleVerifying flight, train, or event times pulled from a third-party API

Why store dates in UTC?

UTC is the one timeline that every machine on Earth agrees on. A datetime stored in UTC represents the same instant in every zone, sorts correctly, subtracts cleanly, and is immune to DST. Storing in "local" time creates a nightmare every March and November: rows duplicate during fall-back, others vanish during spring-forward, and any analytics query that crosses the boundary becomes wrong. The right pattern is universal: store UTC, render in the user's zone at display time. This converter is the "render in the user's zone" half of that pattern made visible — feed it any UTC instant and see what humans across the globe will actually read on their clocks.

Pair with epoch and ISO tools

Convert epoch ↔ ISO, validate RFC 3339, and compare dates with the rest of the DateTime toolkit — every tool runs in your browser.

Unix Timestamp Converter ISO 8601 Validator Date Difference Calculator

Frequently Asked Questions

What is an IANA time zone?

IANA time zones (also called Olson zones or tz database zones) are the canonical identifiers maintained at iana.org/time-zones. Each zone is named like Continent/City — America/New_York, Europe/Paris, Asia/Kolkata — and encodes the full history of UTC offsets and DST rules for that location. Every modern operating system, programming language, and database uses this database under the hood.

Why use "America/New_York" instead of "EST"?

Abbreviations like EST, PST, GMT only describe the current offset — they cannot tell you when DST switches. America/New_York is the real zone: in summer it is EDT (UTC-4), in winter EST (UTC-5), and the database knows the exact dates of every transition back to 1883. Using "EST" in code freezes you at -5 even during DST and silently breaks meeting times every spring and fall.

How does DST work in this tool?

The tool uses Intl.DateTimeFormat with the IANA zone you pick — so DST is handled by the browser's built-in tz database and is always correct for the date you input. If you convert a meeting from America/New_York at 9 AM in January, the displayed UTC offset is -05:00 (EST); the same conversion in July returns -04:00 (EDT). You never have to remember the rules; the browser does.

What about historical time zones?

The IANA database goes back to 1970 with high precision and earlier dates with approximation — for example, before 1883 most US cities used local solar time, with "noon" being slightly different in every town. Browsers ship a recent IANA snapshot, so any date from the last few decades will use the correct historical rules (including the year a country last changed its DST policy or moved to a new zone).

Can I convert future dates accurately?

For dates inside the next year or two: yes, because future DST transition dates are already encoded in the tz database. For dates further out, the conversion uses the rules in effect today and assumes they will not change. Governments occasionally cancel DST or shift zones (Russia, Turkey, Mexico in recent years), so the further out you go the more risk of drift — recheck before scheduling things years ahead.

Are abbreviations like IST ambiguous?

Yes — and IST is the canonical example. India Standard Time is UTC+5:30, Israel Standard Time is UTC+2:00, Irish Standard Time is UTC+1:00. CST is even worse: Central Standard Time (US, UTC-6), China Standard Time (UTC+8), Cuba Standard Time (UTC-5). Always use the full IANA zone (Asia/Kolkata, Asia/Jerusalem, Europe/Dublin) to avoid confusion. The pickers in this tool only offer IANA names for that reason.

How do I get the user's local time zone in JavaScript?

Use Intl.DateTimeFormat().resolvedOptions().timeZone — it returns the IANA zone the browser is configured for (e.g. "America/Los_Angeles"). This is the same value the Now button in this tool uses to detect your zone. Avoid trying to derive it from new Date().getTimezoneOffset(), which gives you the offset in minutes but not the zone name and cannot tell DST-aware periods apart.

Why store dates in UTC?

UTC is the only globally unambiguous timeline. Storing as UTC means the same instant has the same string everywhere, sorting works, arithmetic works, and there is no DST surprise. Convert to a user's local zone only at the rendering layer (this tool, an Intl.DateTimeFormat call, a date-fns formatInTimeZone). Storing in local time is the single biggest source of "the report ran twice on DST night" and "the cron job missed an hour" bugs.