Time Zone Converter & Meeting Planner
Convert a time across multiple cities at once and instantly see the overlapping working hours — the sane way to schedule a meeting across the globe.
Interactive Client Prototype Sandbox
No hour keeps every city inside 08:00–20:00.
Disclaimer: This free tool is provided “as is,” without warranties of any kind, and is for general informational purposes only — not professional, legal, financial, medical, tax, or engineering advice. Results may contain errors; verify anything important independently and use at your own risk. We accept no liability for any loss or damage arising from its use. See our Terms of Use for details.
Step-by-Step Guide
Set the source date and time using the date/time pickers and select the source timezone from the dropdown (or use your browser's detected local timezone). Add destination cities or timezones using the search field — type a city name or a timezone identifier (e.g. 'America/Chicago', 'Europe/Paris') and select from the dropdown.
Each row in the results shows the local time and date in that timezone at the source moment you entered. UTC offset for each city is displayed and automatically adjusts for daylight saving time on the relevant date. The 24-hour grid below the city list shows all hours in each timezone side by side, with the 8am–8pm working window highlighted in each row — making it easy to see which hours overlap for all parties.
Source: 9:00 AM, Monday, New York (EST/UTC−5 or EDT/UTC−4 depending on season). Add London (UTC+0 or BST UTC+1) and Tokyo (JST UTC+9, no DST). In March (EDT active): 9am New York = 2pm London = 10pm Tokyo. The overlap grid shows 9am–noon New York (2pm–5pm London) highlighted as working hours for both New York and London; Tokyo's working hours (9am–5pm JST = midnight–8am New York) do not overlap — visually clear in the grid.
Who it's for
Remote teams, freelancers with global clients, travelers, and anyone scheduling across borders.
Core Features
- Convert one instant into any number of chosen cities using the browser's own time-zone database.
- Automatic daylight-saving handling and live UTC offsets per city.
- A 24-hour grid that highlights the hours that fall within 8am–8pm for every city.
- Add or remove cities on the fly; fully offline.
🛡️ No tracking — your inputs, keys, and details never leave this client sandbox.
How does the tool handle daylight saving time?
The tool uses the browser's Intl.DateTimeFormat API with the IANA timezone database, which includes all historical and future DST transition rules for every timezone. When you enter a specific date and time, the tool automatically applies the correct UTC offset for that timezone on that date — including whether DST is active or not. For example, New York in January is UTC−5 (EST) but in June is UTC−4 (EDT).
What is a UTC offset?
UTC (Coordinated Universal Time) is the international time standard with no offset. All other timezones are defined as offsets from UTC: Eastern Time in the US is UTC−5 (or UTC−4 during DST), London is UTC+0 (or UTC+1 during BST), Tokyo is UTC+9 (Japan does not observe DST). The offset tells you how many hours ahead or behind UTC the timezone is at that moment.
What is the best overlap time for a global meeting?
The 24-hour grid highlights 8am–8pm in each row — a proxy for 'reasonable working hours.' The columns where all rows are highlighted simultaneously are the overlap window. For New York, London, and Tokyo, there is typically no three-way overlap in standard business hours because the time difference between Tokyo and the US East Coast is 13–14 hours. The grid makes this immediately obvious without mental arithmetic.
Can I add any city in the world?
The city list covers major population centers and their IANA timezone identifiers. If your city is not listed, you can search by timezone name (e.g. 'Asia/Kolkata' for India Standard Time) and that timezone will be added. The IANA timezone database (also called the Olson database) includes ~600 timezone regions covering every permanently inhabited location on Earth.
Three things about time zones that make them harder than they look
Time zone conversion seems like simple addition and subtraction from UTC. In practice, three realities make it consistently more complex than that — and each one has caused real-world scheduling failures in distributed teams.
Myth vs. reality: UTC offsets are not fixed
Myth: every time zone has a single, permanent offset from UTC. Reality: most time zones shift twice a year due to daylight saving time. New York is UTC−5 in winter (EST) and UTC−4 in summer (EDT). London is UTC+0 in winter (GMT) and UTC+1 in summer (BST). This means the same "9 AM New York time" maps to different UTC moments depending on the season — and the transition dates differ between the US (second Sunday in March) and the EU (last Sunday in March), creating a period of about two weeks each spring where the US-Europe offset is different from the rest of the year.
Myth vs. reality: all time zones are whole-hour offsets from UTC
Myth: the world divides neatly into 24 hour-wide time zones. Reality: India Standard Time is UTC+5:30. Nepal Standard Time is UTC+5:45. Iran Standard Time is UTC+3:30. Lord Howe Island in Australia applies a 30-minute daylight saving shift, giving it UTC+10:30 or UTC+11. Chatham Islands (New Zealand) is UTC+12:45. These half-hour and quarter-hour offsets exist for geographic, political, or religious reasons and make mechanical offset arithmetic unreliable — you need a database that knows each zone's actual rules.
Myth vs. reality: time zone rules are stable
Myth: once you know a time zone's rules, they don't change. Reality: governments change their DST rules regularly. Russia abolished DST in 2014 (and changed it twice before that). Turkey switched to permanent summer time in 2016. North Korea changed its UTC offset in 2015 and again in 2018. Morocco pauses DST during Ramadan. Samoa switched from UTC−11 to UTC+13 in 2011, skipping a day entirely. The IANA timezone database — embedded in every browser, operating system, and programming language — is updated several times a year to track these changes. This is why this tool uses the browser's Intl API rather than hardcoded offset tables.