Convert a date and time between any two IANA time zones with DST handled.
Uses your browser's IANA tzdata — DST transitions are handled correctly. For aviation/medical use, always confirm against the official source.
Scheduling a meeting across time zones is the daily friction of remote work. "Tuesday at 4pm Paris" is unambiguous to a Parisian and ambiguous to everyone else: is that Pacific Daylight Time at 7am or Pacific Standard Time at 7am, depending on whether spring or autumn? Daylight saving time disagrees across hemispheres (Sydney rolls back when Paris springs forward) and across decades (in 2024 most of South America abandoned DST entirely). The IANA tzdata project maintains the canonical mapping of every named time zone to its offset history, and every modern browser ships a local copy that handles the rules automatically. This calculator is the user-facing wrapper around that data: enter a date, a wall-clock time, and a source time zone; pick a destination time zone; get the equivalent local wall-clock time at the destination, plus the offset between the two zones for that specific instant. The 20 cities in the dropdown cover the majority of cross-time-zone meetings: the major European capitals, the U.S. continental zones, the four primary Asian business hubs, the southern-hemisphere business cities, and UTC as the unambiguous reference.
There is no closed-form formula — the calculator delegates to the browser's Intl.DateTimeFormat API, which has access to the IANA tzdata via the operating system. Internally: (1) Build a UTC instant that, when interpreted in the source time zone, displays the user's specified wall clock. This requires a small two-pass loop: take the inputs as if they were UTC, ask Intl what the source zone shows for that instant, compute the offset between displayed and intended wall-clock, subtract that offset to find the actual UTC instant. (2) Format the same UTC instant in the destination zone using Intl.DateTimeFormat with timeZone: <destination>. (3) Compute the offset difference between the two zones for that specific instant — needed because the offset is not fixed; it varies with DST. The result includes weekday, full date, hour-and-minute, and the zone abbreviation (CET, EST, JST, etc.) for clarity.
Four inputs: date (date picker), time (24-hour time picker), source time zone (dropdown), destination time zone (dropdown). Defaults: today at 14:30, Paris to New York. The result panel shows the source time and the destination time as two large parallel KPIs, and below them the UTC reference time and the offset between the two zones for that instant. The 20-city dropdown covers Europe (Paris, London, Berlin, Moscow), the Americas (New York, Chicago, Denver, Los Angeles, São Paulo), Africa (Cairo, Johannesburg), Asia (Dubai, Mumbai, Beijing, Tokyo, Singapore, Seoul), Oceania (Sydney, Auckland), plus UTC. Add new cities by editing the dropdown; the underlying machinery handles any IANA zone identifier.
A Paris team wants to schedule a kickoff with their New York counterpart on 15 May 2026 at 14:30 Paris time. Source: 14:30 on 15 May 2026 in Europe/Paris (CEST, UTC+2 in May because DST is in effect). Destination: America/New_York (EDT, UTC-4 in May). Source-to-UTC: 14:30 - 02:00 = 12:30 UTC. UTC-to-destination: 12:30 + (-04:00) = 08:30 EDT. So 14:30 Paris = 08:30 New York on the same day, a 6-hour offset. Now consider 15 January 2026 at 14:30 Paris (CET, UTC+1) → New York (EST, UTC-5). Source-to-UTC: 14:30 - 01:00 = 13:30 UTC. UTC-to-destination: 13:30 - 05:00 = 08:30 EST. Same wall-clock conversion, but only because both Paris and New York are on standard time; if Paris had switched to summer time and New York had not (a real situation in late March each year), the offset would be 5 hours instead of 6. The calculator handles this transparently: the user does not need to track DST across two zones; the IANA database does it for them. A more dramatic example: 15 December 2026 at 09:00 Sydney (AEDT, UTC+11) → London (GMT, UTC+0). Source-to-UTC: 09:00 - 11:00 = -02:00 UTC, which is 22:00 the previous day. London at 22:00 on 14 December — across the date line in calendar terms, 11 hours apart in clock terms.
First, conflating UTC offset with time zone. "UTC+1" describes the offset; "Europe/Paris" describes the time zone. Paris is UTC+1 in winter and UTC+2 in summer. Hardcoding UTC+1 for "French time" yields a one-hour error from late March to late October. Second, ignoring DST. Paris and New York both observe DST but on different schedules: in mid-March, Paris is still on CET (UTC+1) for two weeks while New York has already switched to EDT (UTC-4); the offset is 5 hours instead of 6 during that window. The calculator handles this; manual conversions usually get it wrong. Third, mixing 12-hour and 24-hour notation across cultures. The U.S. and U.K. use 12-hour AM/PM clocks colloquially; continental Europe uses 24-hour. The picker in the calculator is 24-hour; the destination output also uses 24-hour for unambiguity. Fourth, scheduling over a date-line crossing without noticing. Tokyo at 09:00 Tuesday is San Francisco at 17:00 Monday — a 16-hour offset that crosses the calendar day. The calculator displays the full date in the destination, not just the time, to make this visible. Fifth, treating the converter as authoritative for legal or aviation use. The calculator uses the browser's tzdata, which is updated when the OS is updated; if the user is on an old system, the rules may be out of date for recent DST changes (e.g., Brazil's 2019 DST abolition, Mexico's 2022 partial DST removal). For binding contexts, always cross-check the official source.
Time zones are a politically-fluid system. DST changes are common: the EU has been debating ending DST since 2018 (no consensus reached as of 2025); Russia abolished DST in 2014; Mexico abolished it in most regions in 2022; Iran abolished it in 2022. The IANA tzdata project tracks all these changes and ships updates several times per year; modern operating systems pull these automatically. Half-hour and quarter-hour offsets exist: India is UTC+5:30, Iran UTC+3:30, Newfoundland UTC-3:30, Nepal UTC+5:45, the Chatham Islands UTC+12:45. The calculator handles these transparently because IANA does. Polar regions use whatever zone is administratively convenient; Antarctic stations may follow the time of their supplying nation. Historical conversions (a 1956 meeting time in Berlin to NYC) are also supported by IANA, which records the entire offset history for each zone. Programmatic conversions in code should always store timestamps in UTC and convert to local time only at display; this calculator demonstrates the conversion at the boundary, where the user sees the result.