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.
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, and 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.