We use minimal cookies for analytics. See ourCookie Policy.
Timezone Converter
Interpreted in the "From" timezone
Error
Target time
UTC equivalent
Offsets
—
Difference
—
Calendar date
—
A timezone converter translates a specific date and time in one place into the equivalent moment as it’s experienced somewhere else. That sounds like simple arithmetic — add or subtract an offset — but the offset itself isn’t fixed: most of the world’s timezones shift by an hour twice a year for daylight saving time, and exactly when they shift depends on the specific zone and the specific date, not a single rule that applies everywhere. Two zones that share the same UTC offset in January can differ by an hour in July, and a handful of zones (Arizona, most of it, is a well-known example) don’t observe daylight saving at all.
This tool doesn’t hardcode any of those rules. It asks the browser’s built-in Intl.DateTimeFormat API — which already ships with the full IANA timezone database and keeps it updated with the browser itself — what a given zone’s UTC offset actually was at the exact instant being converted, then applies that offset to compute the result. That’s the same zero-dependency technique this site’s Unix Timestamp Converter uses for its local-time conversion, extended here to work between any two named zones instead of just “local” and UTC.
Enter a date and time, pick the timezone it’s in (“From”) and the timezone you want to see it in (“To”), and the result updates as you type. Alongside the converted time, the tool shows both zones’ UTC offsets side by side, the plain difference between them, and — separately, since it’s easy to miss — whether the conversion lands on a different calendar date, which happens more often than it might seem once a source and target zone are far enough apart. A “Swap” button flips the two zones without re-entering the date, useful when you’re checking a conversion in both directions.
Every named zone follows the IANA Area/Location naming convention (e.g. America/New_York, Asia/Tokyo) rather than a fixed offset like “UTC-5”, specifically because the named form is the one that stays correct across a DST transition — a plain offset would silently go stale the moment the clocks change. All conversion happens locally in your browser; nothing you enter is sent anywhere.
Examples
Scheduling a call between UTC and America/New_York — enter the proposed UTC time, set "To timezone" to America/New_York, and read off the local time your counterpart will actually see, including whether it lands before or after their working hours.
Converting a UTC API deadline to IST — set "From timezone" to UTC, paste in the deadline from the API docs, and set "To timezone" to Asia/Kolkata to see exactly when it falls in Indian Standard Time, without doing the +5:30 offset math by hand.
Cross-checking a server log timestamp — convert a log's UTC date and time into your own local zone here, then paste that same instant's Unix timestamp into the Unix Timestamp Converter tool to get the raw epoch value some other system expects.
Frequently asked questions
How does this tool handle daylight saving time (DST)?
It doesn't apply DST rules itself — it asks the browser's Intl.DateTimeFormat API what a zone's UTC offset actually was at the specific instant being converted, and that API already has the correct DST transition dates built in for every IANA timezone. That's why converting the same clock time in America/New_York can produce a different UTC offset in January (EST, UTC-5) than in July (EDT, UTC-4) — the tool isn't guessing, it's reading the zone's real rules for that exact date.
What's the difference between a UTC offset and a timezone?
A UTC offset (like UTC-05:00) is just a number — how far a clock reading is from UTC at one moment. A timezone (like America/New_York) is a named region with a full history and future schedule of offset changes, including when it switches in and out of daylight saving time. Two dates in the same timezone can have different offsets (see the DST question above), which is why this tool asks for a named zone, not a raw offset — a raw offset alone can't tell you whether DST applies on a given date.
Can two timezones have the same UTC offset but different DST rules?
Yes, and it's a common source of scheduling mistakes. For example, America/Phoenix (Arizona) does not observe daylight saving time, while America/Denver is one hour behind it in winter but matches it in summer — both are UTC-7 for part of the year and diverge for the rest. Always convert using the named zone, not a memorized offset, since the offset for a given zone can shift twice a year.
Why does the date sometimes change when I convert between timezones?
Because timezones don't just shift the clock, they can shift which calendar day it is. Converting 00:30 in Tokyo to Los Angeles time lands on 07:30 the previous day there, since Los Angeles is far enough behind UTC that its calendar hasn't reached the next day yet. This tool flags that explicitly in the "Calendar date" line of the result, rather than leaving it for you to notice by comparing two dates by eye.
Does this tool store or send my date/time anywhere?
No. The conversion runs entirely in your browser using the built-in Date and Intl.DateTimeFormat APIs — nothing you enter is transmitted to a server, logged, or stored beyond the current page session.