Timezone Converter

Convert times between IANA timezones with proper DST handling

Timezone Conversion

Conversion Result

From (UTC)June 4, 2026 at 18:46:00 UTC
To (America/New_York)June 4, 2026 at 14:46:00 EDT
Time Difference-4h 00m
Date DifferenceSame day

Popular Timezones

UTCUTC
18:46:00
UTC+00:00 STD
New YorkET
14:46:00
UTC-04:00 DST
LondonGMT
19:46:00
UTC+01:00 DST
TokyoJST
03:46:00
UTC+09:00 STD
SydneyAEST
04:46:00
UTC+10:00 STD

All Available Timezones

UTC (Coordinated Universal Time)UTC
New York (Eastern Time)America/New_York
Chicago (Central Time)America/Chicago
Denver (Mountain Time)America/Denver
Los Angeles (Pacific Time)America/Los_Angeles
Toronto (Eastern Time)America/Toronto
Vancouver (Pacific Time)America/Vancouver
London (GMT/BST)Europe/London
Paris (CET/CEST)Europe/Paris
Berlin (CET/CEST)Europe/Berlin
Rome (CET/CEST)Europe/Rome
Moscow (MSK)Europe/Moscow
Tokyo (JST)Asia/Tokyo
Shanghai (CST)Asia/Shanghai
Seoul (KST)Asia/Seoul
Singapore (SGT)Asia/Singapore
Dubai (GST)Asia/Dubai
Kolkata (IST)Asia/Kolkata
Sydney (AEST/AEDT)Australia/Sydney
Melbourne (AEST/AEDT)Australia/Melbourne
Auckland (NZST/NZDT)Pacific/Auckland
Honolulu (HST)Pacific/Honolulu

Timezone Information

Daylight Saving Time (DST)

DST is the practice of setting the clock forward by one hour during the warmer months to extend evening daylight. This affects many timezones around the world.

UTC Offset

The UTC offset shows how many hours and minutes ahead or behind UTC a timezone is. Positive values are ahead of UTC, negative values are behind.

Timezone Abbreviations

Common abbreviations like ET (Eastern Time), GMT (Greenwich Mean Time), and JST (Japan Standard Time) help identify timezones quickly.

Timezone Converter

Convert times between IANA timezones with proper DST handling

Features

  • Convert any wall-clock date and time between 22 IANA tz database zones spanning every populated continent (UTC, America/*, Europe/*, Asia/*, Australia/*, Pacific/*)
  • Conversion uses Intl.DateTimeFormat.formatToParts to find the exact UTC instant for a wall-clock in the From zone, so DST transitions and historical rule changes are honoured automatically
  • Per-zone DST badge computed by comparing the entered date's offset against January and July offsets in the same year — accurate even on the day of a spring-forward or fall-back
  • Standard abbreviation (ET, GMT, JST, IST, AEST) shown alongside the canonical IANA name to avoid the EST/EDT/CST ambiguity that bites cross-team scheduling
  • Popular Timezones strip with live current-time readouts for UTC, New York, London, Tokyo, and Sydney — auto-refreshes every 30 seconds for an at-a-glance world clock
  • One-click swap between the From and To zones to invert a conversion without retyping the date or time
  • Date-aware difference output: same day, next day, previous day, N days, N months, or N years apart — instantly see when a conversion crosses midnight or the international date line
  • Times rendered in your active interface language: month names, day-period markers, and locale-correct number formatting all follow the page locale

How to use

  1. Pick the From timezone — the zone in which the wall-clock time you want to convert is currently expressed.
  2. Pick the To timezone you want to translate into; UTC is a good default if you're producing logs or storing timestamps.
  3. Enter the date and time, or hit Now to snap both fields to the current moment in your local browser zone.
  4. Read the conversion result: the formatted local time in each zone, the offset difference in hours and minutes, and any date crossover.
  5. Use Swap to flip From and To when you need the inverse conversion (e.g., translating a deadline back to your origin zone).
  6. Glance at the Popular Timezones strip for a world clock that auto-refreshes; use the All Available Timezones list to pivot quickly via Use as From / Use as To.

Tips & Best Practices

  • Always specify the timezone when working with timestamps to avoid confusion.
  • Use UTC as the standard reference timezone for international applications.
  • Double-check daylight saving time transitions when converting dates.
  • Bookmark frequently used conversions for faster access.
  • Copy results directly into your code or configuration files.

FAQ

Why do you use IANA names like America/New_York instead of EST?

EST refers to a fixed UTC-5 offset, but New York actually shifts between EST (UTC-5) and EDT (UTC-4) twice a year. The IANA tz database (also called the Olson database) tracks every historical rule change for each region, so America/New_York means "whatever offset New York is observing on the date in question" — including DST, war-time changes, and 1883-style railroad-time switches. Using IANA names avoids the EST-vs-EDT bug class entirely.

How does the converter handle daylight saving time?

The conversion calls Intl.DateTimeFormat with each timezone, which delegates to the host ICU library backed by the bundled tz database. That library knows when each region springs forward or falls back on the specific date you entered, so converting 2026-03-08 02:30 in America/New_York correctly handles the spring-forward gap. The DST badge on each zone shows whether the zone is currently observing DST; the conversion itself uses the correct offset for the entered date.

Why is the result sometimes a day ahead or behind?

Time zone math wraps around midnight. If you convert 22:00 New York time to Tokyo, the result is 11:00 the next day because Japan is 13–14 hours ahead. The Date Difference field calls this out ("Next day" / "Previous day" / "N days apart") so you don't accidentally schedule a meeting on the wrong calendar day. For zones near the international date line — Honolulu, Auckland — date shifts are routine.

Does anything I type get sent to a server?

No. Everything runs in your browser using the built-in Intl and Date APIs. The tz database is part of your browser/OS — we don't fetch zone rules from a server, and we don't log the dates or times you enter. The tool also works offline once the page is cached.

How accurate are the offsets near DST transitions?

Accurate to the minute, because the underlying ICU/tz database tracks transition rules. The one ambiguity is times that don't exist (the lost hour during spring-forward) or times that exist twice (the repeated hour during fall-back). The browser resolves these by convention — typically picking the second occurrence — so if you're scheduling automation around DST, prefer UTC for the storage timestamp and convert only for display.

Will historical conversions be correct for dates before DST rules changed?

For most regions, yes — the tz database records rule changes back to roughly 1970 with reasonable accuracy. For dates before 1970 or for jurisdictions with poor historical records, results may diverge from what clocks actually showed at the time. If you're converting historical timestamps for legal or research work, cross-check against an authoritative tz source like the IANA tzdata release notes.

Can I add timezones outside the 22 in the dropdown?

The dropdown covers the most-requested business zones plus UTC. Browser support extends to all 350+ IANA names, so contact us if you need Africa/Lagos, America/Sao_Paulo, or any other zone added — the underlying conversion already supports them, only the dropdown is curated for usability.

Should I store timestamps in UTC or local time?

UTC. Always. Store an ISO-8601 UTC string (or Unix epoch seconds) in your database, and convert to local time only at the presentation layer using the user's IANA zone — exactly what this tool does interactively. This avoids data corruption when servers move, hosts switch DST policies, or political boundaries shift.