Time Zone Converter with Date and Time
Convert a date and time between supported IANA time zones. Review the selected date because daylight-saving offsets can change throughout the year.
Convert Specific Time
Now in UTC:
UTC offset —
Live World Clock
Los Angeles
16:00:00
Wed, Dec 31
-08:00
New York
19:00:00
Wed, Dec 31
-05:00
London
01:00:00
Thu, Jan 01
+01:00
Berlin
01:00:00
Thu, Jan 01
+01:00
Dubai
04:00:00
Thu, Jan 01
+04:00
Mumbai
05:30:00
Thu, Jan 01
+05:30
Singapore
07:30:00
Thu, Jan 01
+07:30
Tokyo
09:00:00
Thu, Jan 01
+09:00
Sydney
10:00:00
Thu, Jan 01
+10:00
Every IANA Zone
Uses Intl.supportedValuesOf("timeZone") to load the complete IANA database your browser ships with — typically 400+ zones, always current with the latest DST rule changes.
Live World Clock
Side-by-side board of nine major cities ticking once per second. Add or remove cities, switch to 12/24-hour, or expand any tile to view the full ISO timestamp.
DST & Offset Aware
Each zone shows current UTC offset and whether it is currently observing daylight saving time. Convert across DST boundaries without arithmetic mistakes.
100% Client-Side
No clock data leaves your browser. All formatting and offset math runs through native Intl APIs. Works offline once the page is loaded.
Time Zone Converter: Translate Any Time Between IANA Zones
Convert a date and time between supported IANA time zones. Review the selected date because daylight-saving offsets can change throughout the year. A timezone name contains rules; a fixed UTC offset does not. Daylight-saving transitions can create local times that occur twice or do not occur at all. Verify the destination date and offset when scheduling across regions, particularly near a clock change.
How to use the time zone converter
- Set the From zone. The tool defaults it to your detected local zone via
Intl.DateTimeFormat().resolvedOptions(). - Pick the To zone (UTC by default). Type a city name in the dropdown to filter the full IANA list fast.
- Enter the date and time in the From field, or click use current to drop in the live time for that zone.
- Read the converted time on the right, with its UTC offset and a DST active / standard time badge for that instant.
- Need the unambiguous value? Copy the ISO 8601 string (e.g.
2026-05-11T14:30:00.000Z) shown below the result. - Use the swap arrow to reverse direction, or toggle 12-hour format for AM/PM output.
What is a time zone, and why isn't the offset fixed?
A time zone is a region that keeps a common offset from Coordinated Universal Time (UTC), the atomic-clock reference behind GPS, aviation, and internet protocols. The offset is written as +HH:MM or −HH:MM — New York is UTC−05:00 in winter but UTC−04:00 in summer, while India sits at a fixed UTC+05:30. The offset is not a constant property of a place: it moves at Daylight Saving Time transitions and, historically, whenever a government changed the rules.
That is why this converter uses IANA zone names, not abbreviations. The IANA Time Zone Database (the tz or zoneinfo database, release 2026b, maintained by Paul Eggert and Tim Parenti) records the full history of offset and DST-rule changes for every region. Your operating system ships it, your browser exposes it through Intl.DateTimeFormat, and this tool reads it directly — so the math always reflects the current rules with no network call. For storage and exchange, pivot through UTC and write the ISO 8601 form with a Z suffix (the "Zulu" designator for a zero UTC offset).
"The Time Zone Database… is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules."— IANA, iana.org/time-zones
Worked examples: source → target
London 09:00 → Tokyo (summer, BST active)
Europe/London is UTC+01:00 on a July morning, Asia/Tokyo is a fixed UTC+09:00. 09:00 in London → 17:00 the same day in Tokyo (an 8-hour gap that shrinks to 9 hours in winter).
New York 23:00 Mon → Sydney
With a wide offset gap, the weekday flips: 23:00 Monday in America/New_York lands on Tuesday afternoon in Australia/Sydney. The result tiles show day-of-week so a "Monday standup" doesn't silently become Tuesday.
Mumbai 10:00 → UTC
Asia/Kolkata is UTC+05:30, a half-hour offset. 10:00 in Mumbai → 04:30 UTC — the kind of result that hand-math gets wrong by 30 minutes.
Edge case · the nonexistent spring-forward hour
On a US spring-forward day, clocks jump from 1:59:59 straight to 3:00:00, so 2:30 AM never occurs. Enter that nonexistent wall time and the converter doesn't error — it uses the offset it computes for that instant and rolls the result forward into the 3 AM hour. Fall-back is the mirror image: 1:30 AM happens twice, so a duplicated local time maps to two distinct UTC instants.
Common time zone abbreviations decoded
Abbreviations are ambiguous — "CST" alone means US Central, China Standard, or Cuba Standard Time. Use this for human reference, but in code always use the IANA zone name in the last column.
| Abbreviation | Full Name | UTC Offset | Notes |
|---|---|---|---|
| UTC | Coordinated Universal Time | +00:00 | Atomic-clock reference; no DST. Use this in logs and APIs. |
| GMT | Greenwich Mean Time | +00:00 | Same as UTC in practice; specifically the winter offset of the UK. |
| EST / EDT | Eastern (Standard / Daylight) | -05:00 / -04:00 | New York, Toronto, Atlanta. Switches second Sunday in March. |
| PST / PDT | Pacific (Standard / Daylight) | -08:00 / -07:00 | Los Angeles, Seattle, Vancouver. |
| CET / CEST | Central European (Standard / Summer) | +01:00 / +02:00 | Berlin, Paris, Madrid. DST last Sunday March → last Sunday October. |
| IST | India Standard Time | +05:30 | Half-hour offset; no DST observed. |
| JST | Japan Standard Time | +09:00 | No DST. Same time year-round. |
| AEST / AEDT | Australian Eastern (Standard / Daylight) | +10:00 / +11:00 | Sydney, Melbourne. DST first Sunday October → first Sunday April. |
How the DST badge is actually decided
Browsers don't expose a direct "is DST active" flag, so this tool computes it. For the instant you're viewing, it measures the zone's offset on January 1 and on July 1 of that year. If the two match, the zone observes no DST and the badge stays on standard time. If they differ, the larger offset is the daylight period — and the badge lights up only when the current instant's offset equals that larger value. That's why a zone correctly reads "DST active" on April 15 but "standard time" in December, computed per-instant rather than per-zone.
One real gotcha this exposes: the heuristic assumes the summer offset is larger than the winter offset, which holds for the Northern Hemisphere and for Southern-Hemisphere zones like Australia/Sydney alike (the comparison takes the max, not "July"). It also normalizes a browser quirk where formatToParts reports midnight as hour 24 instead of 0 — left unhandled, that would throw the offset math off by exactly 24 hours at midnight.
Time zone mistakes that cause real bugs
1. Storing "Local Time" Without A Zone
A value like "2026-05-11 14:30" with no zone is meaningless across users. Store UTC (ISO 8601 with a Z suffix) in the database and convert to user-local only at display time.
2. Hard-Coding UTC Offsets
Writing "Berlin = UTC+1" is wrong half the year — Berlin is +1 in winter, +2 in summer. Use the IANA name so the runtime applies the correct DST-aware offset.
3. Confusing The +/− Sign
UTC−05:00 is behind UTC (later in the day arrives first in the east). New York at 14:00 is 19:00 UTC, not 09:00. Subtract a negative offset, don't add it.
4. Ignoring Day-Of-Week
Scheduling "Monday 9 AM London" for a Sydney participant lands on Monday evening or Tuesday morning. Always verify the weekday across zones for recurring events.
Related date, time & calculator tools
Unix epoch ↔ ISO 8601 date
Date Difference CalculatorDays and weeks between two dates
Age CalculatorExact durations across calendar months
Cron Expression BuilderSchedule jobs across server zones
Pomodoro TimerFocus blocks across time zones
Unit ConverterConvert length, mass & more
UUID Generatorv7 IDs embed millisecond UTC
Percentage CalculatorQuick percentages and changes
Guide: Unix Timestamps & EpochHow epoch time and UTC fit together
All ToolsBrowse the full Toolk hub
Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.
Frequently asked questions
How does the converter handle daylight saving time correctly?
It never hard-codes an offset. Every conversion goes through the browser's native Intl.DateTimeFormat, which reads the IANA Time Zone Database shipped with your OS and applies the rules in force for the exact instant you entered — so New York resolves to UTC−05:00 in January but UTC−04:00 in July automatically, with a DST-active badge computed per instant.
What happens if I enter a wall-clock time that never existed?
Spring-forward transitions skip an hour — on a US changeover day the clock runs 1:59:59 then jumps straight to 3:00:00, so 2:30 AM does not occur. Rather than erroring, the converter rolls that input forward into the post-transition hour; the fall-back mirror case is trickier still, since a duplicated 1:30 AM maps to two distinct UTC instants.
Are my meetings or travel dates transmitted anywhere?
No. All offset math runs locally through Intl APIs reading the IANA database on your own machine, so tool input is not sent to Toolk — Toolk's page analytics do not receive the times or zones you pick — and the converter keeps working offline once loaded.
Why should I store ISO 8601 instead of a local time string?
A bare “2026-05-11 14:30” loses its zone and means something different to every reader, while an ISO string with a Z suffix names one unambiguous instant. Convert your event here, copy the ISO output for storage, and use Toolk's timestamp converter (/tools/timestamp-converter) when you need the same instant as a Unix epoch integer.