Convert any wall-clock time in any IANA timezone into the matching moment in every other zone in a world clock, including your local zone. DST-correct, half-hour-offset aware, and uses the browser’s native timezone database — no external library, no hardcoded offset tables.
How it works
The tool needs two inputs:
- Source timezone — an IANA zone identifier like
America/New_York,Europe/London,Asia/Kolkata. Defaults to your browser’s local zone, which is auto-detected on load. - Wall time in that zone — the clock reading as it would appear to someone in that zone, as a simple
YYYY-MM-DDTHH:MMstring. There’s no timezone marker on this input — that’s the point, the source zone provides it.
Given those two, the tool computes the underlying UTC instant, then displays that same instant in every zone in the world-clock roster. The result card shows each zone’s wall time, offset from UTC, and short timezone name (like “EDT”, “CET”, “JST”) when the browser provides one.
Under the hood, it’s all Intl.DateTimeFormat with the timeZone option — the same API backend developers use when they need to format a server timestamp for a user in a different region. The browser’s Intl data is updated via OS updates, so DST rule changes (Mexico ended most DST observance in 2022, Kazakhstan abolished it in 2024) flow through without this tool needing to change.
Example: NYC to London
You have a meeting on Wednesday, April 15, 2026 at 09:00 New York time and you need to know what time that is for your London colleagues. Set the source zone to America/New_York, set the wall time to 2026-04-15T09:00, and read off the London row: 14:00 on the same date. BST (UTC+1) versus EDT (UTC−4) = 5 hours ahead.
Because this is April 15, both regions are in their summer-time offset (EDT and BST), not winter (EST and GMT). The difference between them stays 5 hours for most of the year — but in the two-week window in March when the US has sprung forward and Europe hasn’t, it’s only 4 hours. The tool handles that automatically; you don’t have to memorize the calendar.
Example: Tokyo to LA, across the dateline
A team member in Tokyo schedules a call for 09:00 JST on Wednesday July 15, 2026. What time is that for your LA colleague? Set the source zone to Asia/Tokyo, wall time 2026-07-15T09:00, read off the Los Angeles row: 17:00 on Tuesday July 14, 2026 — the previous day. Tokyo is JST (+09:00), LA is PDT (−07:00), difference is 16 hours, crossing the dateline backward.
This is the case that catches people out most often — “Wednesday morning Tokyo” is “Tuesday afternoon LA”, not “Tuesday morning” or “Wednesday afternoon.” The world clock makes the date rollover visible on the right row, so there’s no confusion.
Example: India’s half-hour offset
A database column stores UTC timestamps and you need to tell a Mumbai colleague what time a report was generated. Set the source zone to UTC, wall time to whatever the column says (say 2026-04-15T06:30), and read off the Mumbai / Delhi row: 12:00. India runs on UTC+05:30, a half-hour offset, which confuses tools that assume all zones are on hour boundaries. This one doesn’t — Intl handles it natively.
Example: the DST transition edge case
Type 2026-03-08T02:30 with source zone America/New_York. That clock reading doesn’t actually exist — on that Sunday, the clock jumps from 02:00 EST directly to 03:00 EDT, skipping 02:00–03:00 entirely. The tool resolves this by picking the UTC instant that, when re-formatted in the zone, lands as close as possible to 02:30 — usually 03:30 EDT. The underlying UTC instant is then displayed correctly in all the other zones. You won’t get a red error, but you will see the expected weirdness if you’re working near a transition.
What’s in the world clock roster
Curated list: UTC, Los Angeles, New York, Chicago, Denver, São Paulo, London, Paris, Berlin, Amsterdam, Johannesburg, Dubai, Mumbai / Delhi, Singapore, Shanghai, Tokyo, Sydney, Auckland. Your local zone gets auto-added to that list on first load. Any zone you add via the dropdown is stacked on top and gets a remove × button. The curated cities are pinned — they stay on the clock so you don’t lose the world coverage by accident.
What this tool does not do
It doesn’t schedule across multiple people simultaneously. If you need “what’s the best meeting time for one person in Tokyo, one in London, and one in NYC?” — that’s a meeting-planner tool, not a timezone converter. The world clock shows the same moment in all zones, which is enough for “does 09:00 here work for everyone?” but doesn’t help search for overlapping business-hour windows.
It doesn’t support abbreviations as input — you can’t type “EST” as a source zone. Abbreviations are ambiguous (CST is Central Standard Time in the US, but also China Standard Time in China) and the tool uses IANA zone identifiers (America/Chicago, Asia/Shanghai) to be unambiguous. The output shows the short name when the browser provides one, but input needs the full zone identifier.
It doesn’t save your roster. Each page load starts with the curated list plus your auto-detected local zone. Zones you add during a session are kept until you reload; they’re not persisted to localStorage.
It doesn’t handle historical timezone changes before 1970 reliably. The Intl tzdata covers modern dates well; for old historical dates (pre-1970, or pre-DST-existed) some zones report their current offset rather than the one in force at the time. For any date in the last 50 years, the tool is accurate; for older dates, check a primary source. For the Unix-seconds → wall-clock direction without zones, the Unix timestamp converter is the simpler tool.