Time Zone Converter
Pick a date, time and source time zone, and see that exact moment converted into 15 major world time zones.
About the Time Zone Converter
Time zone offsets shift throughout the year because of daylight saving rules, so this converter never hardcodes a fixed UTC offset for any zone. Instead it hands your chosen date, time and source zone to the browser's built-in Intl.DateTimeFormat API, which carries the real, up-to-date DST transition rules for every IANA zone, and adjusts the underlying instant until it lands on the wall-clock time you entered in that zone. Every target zone below is then formatted straight from that same instant, so the current offset shown next to each city (like UTC-4 or UTC+5:30) is always correct for the specific date you picked, not just a generic average.
A real gap in JavaScript's Date API, and how this tool works around it
JavaScript's built-in Date object has no direct way to say "construct the instant that shows as this wall-clock time in this specific named time zone," it can only be built from UTC components or from your browser's own local system time zone. There's simply no constructor parameter for "and interpret this in Asia/Tokyo specifically." This tool works around that gap with an iterative guess-and-correct approach: it first treats your typed date and time as if it were already a UTC instant (a deliberately wrong starting guess), checks what wall-clock time that guessed instant would actually display as in your chosen source zone using Intl.DateTimeFormat, measures the difference between that displayed time and what you actually typed, and nudges its guess by exactly that difference. It repeats this up to three times, which is enough for the guess to converge precisely even right at the edge of a DST transition, where the offset itself can shift between one iteration and the next.
Why three iterations specifically, not just one
For the vast majority of dates, a single correction pass is already exact, since the offset doesn't change between the initial guess and the corrected instant. The extra iterations exist specifically for the narrow edge case of times sitting close to an actual DST transition boundary, where correcting once might land the guess just close enough that the offset itself flips between the first and second pass. Looping up to three times gives the calculation room to settle into a stable, correct answer even in that edge case, rather than potentially reporting a time that's off by exactly one hour right at a transition boundary.
An honest note on genuinely ambiguous wall-clock times
Twice a year, DST transitions create two categories of wall-clock time that no conversion approach, including this one, can resolve with total certainty on their own: a "spring forward" gap where a stretch of time (like 2:00-2:59 AM in many US zones) never occurs at all, and a "fall back" overlap where a stretch of time occurs twice in the same day. If you pick a date and time that falls inside one of these windows in your selected source zone, the underlying ambiguity is a real property of how that time zone works that day, not a limitation specific to this tool, any calendar or scheduling system faces the identical problem for those same hours.
Why the offset label has a manual fallback calculation
To display something like "UTC-4" next to each city, this tool first tries asking Intl.DateTimeFormat directly for a short offset label. Not every browser implementation supports that specific formatting option equally well, so if it comes back empty, the code falls back to computing the offset manually, by comparing the zone's displayed wall-clock time against the UTC instant in milliseconds and converting the difference into hours and minutes itself. That fallback exists purely for compatibility, ensuring the offset always displays correctly even on a browser whose Intl implementation is slightly less complete.
Frequently Asked Questions
Why can't JavaScript's Date object just take a time zone name directly?
The Date object can only be constructed from UTC components or your browser's local system time zone, there's no built-in way to say "interpret this wall-clock time in this specific named zone." This tool works around that gap with an iterative guess-and-correct calculation using Intl.DateTimeFormat instead.
How does the tool figure out the correct UTC instant for a typed date and time?
It starts with a deliberately wrong guess (treating your input as if it were already UTC), checks what wall-clock time that guess would actually display in your chosen zone, measures the difference from what you typed, and corrects the guess accordingly, repeating up to three times to fully converge even near DST transitions.
Why does the calculation loop up to three times instead of stopping after one correction?
A single correction is exact for most dates, but right at a DST transition boundary, the offset itself can shift between the first guess and its correction. The extra iterations give the calculation room to settle into a stable, accurate result even in that edge case.
What happens if I pick a time that falls in a DST "spring forward" gap?
That specific wall-clock time genuinely doesn't exist in that zone on that day, a property of how DST transitions work, not a limitation unique to this tool. Every calendar or scheduling system faces the same inherent ambiguity for those particular hours.
Why does each city show a different UTC offset depending on the date I pick?
Offsets shift throughout the year due to daylight saving rules in many zones, so this tool recalculates the real offset for your specific chosen date using live IANA time zone data rather than a fixed, potentially outdated lookup table.
Does this tool use a hardcoded list of time zone offsets?
No, every offset and converted time is calculated live from the browser's built-in Intl.DateTimeFormat API using real IANA time zone rules, which stay current with actual DST transition dates rather than relying on a static, potentially stale table.