Timezone Converter
Convert a date and time between time zones, with DST and a day-shift marker.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
Takes a date and time in one IANA time zone and shows the same instant elsewhere. It works out the UTC instant for the wall-clock time you enter — resolving the zone's offset for that specific date, so daylight saving is handled — then formats that instant in the target zone and in a table of major cities. Each row shows the local time, its UTC offset and abbreviation, and a marker when the result falls on the previous or next calendar day relative to your input. It uses the time zone data already built into your browser; nothing is downloaded and nothing is sent anywhere.
When to use it
Questions
Does it handle daylight saving time?
Yes. The offset is resolved for the exact date you enter, so a New York time in January is treated as EST (−5) and the same clock time in July as EDT (−4). The city table reflects each zone's rules for that date independently.
What happens if the local time I enter doesn't exist?
On the morning a clock springs forward, times in the skipped hour never occur. The tool resolves them forward into the new offset rather than rejecting them, so you still get a valid instant — just be aware that clock time was never shown on a wall in that zone.
Why does a result say 'next day'?
When the target zone is far enough ahead, the same instant is already tomorrow there. The marker shows +1 (next day) or −1 (previous day) so a 9am call doesn't get mistaken for the wrong date.
Which time zone list is this?
The IANA time zone database that ships with your browser, listed by its canonical names (America/New_York, Europe/London, and so on). Those names are stable and unambiguous, unlike abbreviations such as CST which mean different things in different countries.
Why does part of the table show a different date?
Because zones far apart sit on different calendar days at the same instant — 23:00 Monday in Los Angeles is mid-morning Tuesday in Sydney. Rows whose date differs from your input carry a +1 or −1 marker, so 'the call lands tomorrow for them' cannot slip unnoticed into a meeting invite. That date-line effect is the single most common cross-timezone scheduling mistake.
How are half-hour and 45-minute offsets handled?
Like any other offset — India is UTC+5:30, parts of Australia +9:30, Nepal +5:45 straight from the IANA rules your browser carries, with nothing special to model. The offset shown is resolved for the specific date you entered, so a zone whose rules changed across your date range reads correctly either side. Pick zones by city rather than by fixed UTC shorthand, which blurs exactly these cases.
What happens when a country changes its clock rules?
Your browser's IANA database decides, and browser updates refresh it. Historical rule changes — Samoa skipping a calendar day in 2011, Turkey abandoning DST in 2016 — resolve according to how current the browser's data is; for present-day scheduling the data is effectively always right. The tool leans on that built-in database rather than bundling its own, which keeps it honest about what it knows.
Why IANA zone names rather than UTC offsets or abbreviations?
Because both alternatives lie to you. Abbreviations collide (CST: China, US Central, Cuba) and fixed offsets ignore daylight saving; IANA names — America/Chicago, Asia/Kolkata — are unique, carry each zone's full DST history, and are the same identifiers backends, cloud providers and databases use. UTC itself remains a valid picker here when you want the neutral reference zone instead of someone's local time.
What does the From zone change?
Everything, because bare clock digits mean nothing until a zone interprets them. The tool resolves your date and time as spoken in the From zone — 21:45 on 2026-03-08 in New York resolves to a different UTC instant than the same digits labeled Sydney — and renders that instant in the To zone and the city table. Enter from the zone whose clock the original statement used: '9am New York time' is From America/New_York no matter where you sit typing.
What happens during a DST shift?
Two edge cases, both handled by resolution rather than rejection: spring-forward skips times that never existed locally (the tool maps them onto the new offset), and fall-back repeats an hour (the first occurrence is used). Date-level answers stay sound across the change because the offset is resolved per specific date; just be aware that a wall time inside a skipped hour was never locally possible.