Timezone Converter

Pick a source timezone, a target timezone, and a date and time. The tool returns the equivalent moment in the target zone, with the UTC offset of each side shown alongside.

Reach for it when scheduling cross-zone meetings, debugging a server log that recorded events in UTC while your monitor reported them in local, or planning travel across multiple time zones. DST transitions are handled — if the source date falls inside a DST window, the offset reflects that; same for the target.

The IANA timezone database underpins the conversions, which means historical accuracy as well as current. A 1985 date in America/Indianapolis correctly uses the offset from before Indiana harmonized with the rest of Eastern Time.

Under the hood, the tool uses the IANA tz database — the same data that powers Linux, macOS, JavaScript Date objects, and most modern programming languages' time handling. The tz database tracks every timezone change in human history: when DST was introduced, when boundaries shifted, when a region switched offsets. A 1985 conversion from America/Indianapolis to America/New_York correctly accounts for the fact that Indiana didn't observe DST in most of the state until 2006.

Worked example. 2026-06-15 14:30 in Europe/London → ? in Asia/Tokyo. London in mid-June is in BST (UTC+1). Tokyo is JST (UTC+9), no DST. Difference: 8 hours. Result: 22:30 local Tokyo time, same date. Try the same conversion in November when London is on GMT (UTC+0): the difference becomes 9 hours, and 14:30 GMT is 23:30 JST. The DST transition shifts the offset; the tool gets the right answer for either date because it uses the full tz database, not a hardcoded offset.

Where offset shorthands fail. Saying "3 PM PST" is ambiguous half the year — Pacific time is on PDT (UTC-7) in summer and PST (UTC-8) in winter. "3 PM Pacific" or the IANA name "3 PM America/Los_Angeles" disambiguates. The tool prefers IANA names because they remove this ambiguity and survive jurisdictional rule changes (e.g., if California ever permanently adopts DST, the IANA name keeps tracking, while a hardcoded "PST" offset becomes wrong).

DST transitions create non-existent and ambiguous times. When the US springs forward, 2:30 AM doesn't exist on the morning of the transition (clocks jump from 1:59:59 to 3:00:00). When clocks fall back in November, 1:30 AM happens twice. The tool flags these edge cases with a warning when you try to convert from such a time. Most production code mishandles these — "meeting at 2:30 AM on March 9" is a UTC-equivalent ambiguity that needs explicit resolution.

A practical opinion: store all timestamps in UTC in your database, convert to user timezone at display time. Store the user's IANA timezone as a separate field ("America/New_York", not "-05:00"). When the user travels, their timezone preference may need updating, but their stored timestamps stay correct. This is the canonical pattern, and it survives DST transitions, jurisdictional rule changes, and global user bases without special cases.