Why this needs the browser's timezone database, not arithmetic#
A timezone offset is not a fixed number. America/New_York is UTC-5 in January and UTC-4 in July, because of daylight saving time — and the date the switch happens changes from year to year, and not every country observes it. Hardcoding "New York is UTC-5" is correct for roughly half of the calendar and silently wrong for the other half.
This tool uses the Intl API built into every modern browser, which ships the same IANA timezone database (America/New_York, Europe/Madrid, and so on) that server-side systems use. The offset for any given date is looked up, not calculated — so DST transitions, and the rare cases where a country changes its rules entirely, are handled correctly without this tool needing to track any of it.
The wall-clock time versus your own timezone#
Enter the time exactly as it would read on a clock in the source location — "3pm in New York" means typing 15:00 and selecting America/New_York, regardless of what time it currently is where you are. This trips people up because most date pickers implicitly assume "your" timezone; this tool asks you to be explicit about whose clock the number belongs to.
Why the day sometimes changes#
A large enough offset means the equivalent time in another zone genuinely falls on a different calendar date. 3pm in New York on a Tuesday is already 4am Wednesday in Tokyo — not a bug, just what a nine-hour-plus offset does to a time near midnight on the other side. Each zone shows whether it lands a day before or after the source date so this does not get missed when scheduling something across a date boundary.