Time Zone Converter
See one date and time in up to 5 zones at once — day shift, the real per-instant UTC offset and the abbreviation. Live, in your browser.
—
All conversion happens in your browser via its built-in IANA time-zone database — nothing is sent anywhere. No hand-written offset tables either: every offset shown is computed by the Intl engine for the exact instant you chose, so daylight-saving switches and odd offsets like +05:45 are always right for that date.
Offline later: once you have opened this page with a connection, it reopens and works with none — your browser keeps a copy. Not saved: the very first Polyatic page you ever open (open it again while online), and any page or link you have never opened.
Meeting planner
Add each attendee’s zone and working hours, pick a date, and read the overlap down the columns. Every column is the same instant in UTC — where the green blocks line up vertically, everyone is at their desk.
Selected time
The planner uses the very same in-browser Intl engine as the converter above — no separate offset tables. That is why the best-overlap band slides by an hour on the weeks when one country has switched to daylight-saving time and another has not.
A zone is not an offset
The single most common time-conversion bug is treating a time zone and a UTC offset as the same thing. An offset — UTC−05:00, UTC+05:45 — is a snapshot: a fixed distance from Coordinated Universal Time at one instant. A zone — America/New_York, Asia/Kathmandu — is a ruleset maintained in the IANA time-zone database: which offset applies when, every daylight-saving switch, and every historical change (New York has used two different offsets every year since 1918; Nepal moved to +05:45 in 1986). That is why this tool asks for a zone and a specific date+time, then computes the offset that actually applied at that instant. Convert with a remembered offset instead, and for roughly two-thirds of the year you can be an hour out.
Worked example: the March mismatch weeks
"New York is 5 hours behind London" is only true for part of the year — and in March it quietly becomes false for three weeks. The US springs forward on the second Sunday of March (2026-03-08), but the UK waits for the last Sunday (2026-03-29). Between those dates New York is on EDT (UTC−04:00) while London is still on GMT (UTC+00:00), so the gap is 4 hours, not 5:
- Mon 2026-03-02, 15:00 in London → 10:00 in New York (5-hour gap, both on standard time)
- Mon 2026-03-16, 15:00 in London → 11:00 in New York (4-hour gap — the mismatch weeks)
- Mon 2026-04-06, 15:00 in London → 10:00 in New York (5-hour gap again, both on summer time)
The same mismatch repeats every late October in the other order: the UK falls back on 2026-10-25, the US on 2026-11-01, so for one week the gap is 4 hours again. A weekly transatlantic meeting pinned by offset drifts by an hour twice a year; pinned by zone, this converter gets each date right. Try it above: set the source to Europe/London, the date to 2026-03-16 15:00, and add America/New_York.
Why "EST" is a trap
Abbreviations are not identifiers. EST is North American Eastern Standard Time (UTC−05:00) — but it is also routinely written for Australian Eastern Standard Time (UTC+10:00), 15 hours away. Worse, people write "EST" all year even though New York actually observes EDT (UTC−04:00) from March to November — so "3pm EST" in July, taken literally, is 4pm New York time. CST collides three ways (Central US, China Standard Time and Cuba). The unambiguous way to name a time is an IANA zone plus a date, which is exactly what this tool works with; the abbreviation badge in each result is shown for recognition, not as an identifier.
Day boundaries: the +1d/−1d badge
One instant, several calendar days. Zones span 26 hours end to end — from UTC−12:00 to UTC+14:00 (Pacific/Kiritimati) — so while it is 23:30 Thursday in London it is already 08:30 Friday in Tokyo and still 15:30 Thursday in Los Angeles. Each result row's day badge (+1d, −1d, same day) is computed against the source zone's calendar date, because that is what bites in practice: a "Monday 09:00 Sydney" meeting is Sunday 18:00 in New York, and a flight that lands "tomorrow" may land the same calendar day you took off. At extreme spreads the badge can even read +2d/−2d — Kiritimati and UTC−12 are two calendar days apart around their midnights.
Honest limits
Offsets come from your browser's own copy of the IANA database, so a badly out-of-date browser could apply an old rule for a country that recently changed its DST policy — governments do this on short notice (Türkiye scrapped DST in 2016; Egypt reinstated it in 2023). During a spring-forward gap, a wall time that never existed (02:30 in New York on 2026-03-08) is resolved deterministically to the instant the pre-transition offset implies — EST −05:00 there, so it converts as 03:30 EDT, on the far side of the gap — and a line above the result tells you that clock time never happened, instead of quietly handing you a reading you did not type. An autumn repeated hour resolves to one of its two possible instants — for times inside those one-hour windows, double-check which side you mean. And this page converts wall-clock times; if what you have is a raw Unix epoch number, the Unix Timestamp Converter owns that job — it auto-detects seconds vs milliseconds and shows UTC, ISO-8601 and local forms.