Pick a source and target city and enter a time to convert it instantly — perfect for scheduling international meetings or catching up with friends abroad.
Every timezone is essentially an offset from Coordinated Universal Time (UTC) — Taipei is UTC+8, New York is UTC-5 in winter. The basic conversion logic is simple: convert the source time to UTC, then apply the target timezone's offset to get the local time there. That's exactly what this tool's convert() function does — it subtracts the source offset from the target offset (in minutes), adds that to your input time, and carries the result forward or back a day whenever the total spills past midnight. The tricky part is that the "offset" itself isn't a constant. Regions that observe daylight saving time — the US, most of Europe, parts of Australia — shift their offset by a full hour twice a year, so the time difference between the same two cities in March can be completely different from December.
A lot of people just remember "Taipei is 12 hours off US East Coast time" or "8 hours off London" — but that's only true for part of the year. Take New York: in winter (Eastern Standard Time, EST) it's UTC-5, a 13-hour gap from Taipei's UTC+8; in summer (Eastern Daylight Time, EDT) the US clocks jump forward an hour to UTC-4, shrinking the gap to 12 hours. Europe's daylight saving dates don't line up exactly with the US (they start and end on different weekends), so in the weeks around a seasonal clock change, mentally applying a "fixed offset" to schedule a meeting can silently put you an hour off. That's exactly why this tool never hardcodes an offset — it uses Intl.DateTimeFormat with shortOffset to query the browser live for each timezone's actual offset "as of today," so the conversion always reflects the rule that's genuinely in effect right now, not a stale mental shortcut.
Say you're in Taipei and need to schedule a video call that works for people in Taipei, London, and New York. Set "From City" to Taipei and enter your proposed Taipei time — say 9:00 PM. Switch "To City" to London; if it's August (UK British Summer Time, BST, UTC+1), the converted result comes out to roughly 2:00 PM. Now switch "To City" to New York (EDT in August, UTC-4), and you get roughly 9:00 AM. At a glance, you can now see that 9 PM Taipei is a comfortable afternoon slot for London and a reasonable start-of-day for New York — a solid window for all three. If instead you'd picked a Taipei middle-of-the-night slot, the converted times would very likely land in the middle of the night for London or New York too — this exact kind of cross-timezone judgment call is the core problem this tool is built to solve.
A timezone conversion doesn't just shift the hour and minute — it can also cross a date boundary. For example, 1:00 AM Wednesday in Taipei converts to Tuesday afternoon in New York, which shows up as "1 day before Taipei." This detail is easy to miss when scheduling international meetings — people often glance only at the clock time and don't notice the date has actually shifted a day forward or back, leading someone to show up on the wrong date. This tool deliberately surfaces the date difference as its own line specifically to prevent that common mistake.
That's normal behavior from daylight saving time, not a calculation error. Any region that observes DST — the US, most of Europe, parts of Australia — shifts its clocks twice a year, changing the offset. This tool always looks up the offset that's in effect for "today's" date, so results around a seasonal clock change are supposed to differ — that's precisely what makes it more accurate than memorizing a fixed number.
It uses the browser's built-in Intl.DateTimeFormat API to query the offset for each timezone "as of today" against the standard IANA time zone database. That database already encodes when each region's daylight saving time starts and ends, so the lookup always reflects the rule genuinely in effect — the tool itself doesn't need to hardcode or maintain any DST rules.
The offset data used for conversion comes from the browser's timezone database lookup, which is independent of whether your computer's current system clock is accurate. The only place your system clock matters is that the "Time" field is pre-filled with your current system time when the page loads — if that's wrong, just edit the field to the correct time; it won't affect the accuracy of the conversion logic itself.
It currently includes 18 commonly used cities, covering Asia (Taipei, Tokyo, Seoul, Shanghai/Beijing, Hong Kong, Singapore, Bangkok, Dubai, New Delhi), Europe (London, Paris, Berlin), the Americas (New York, Chicago, Los Angeles, São Paulo), and Oceania (Sydney, Auckland) — enough to cover most common international scheduling scenarios.
No. The entire conversion runs locally in your browser — there's no code on this page that sends any field's data to a server. Refreshing the page resets every input, and no lookup history is kept anywhere.