Time Zone Converter & Meeting Planner
One moment in time across several cities at once, with the hours that work for everyone highlighted.
Runs entirely in your browser. Nothing you type here is uploaded, stored or logged.
Why time zone maths goes wrong
The offsets people memorise are only true for part of the year. London to New York is "5 hours" — except for about three weeks in March and one in late October, when the two regions have already switched or not yet switched, and the gap is 4 hours.
Those transition weeks are when meetings get missed. The fix is to always calculate for the actual date rather than applying a remembered offset, which is why the date field here is not optional.
Who changes their clocks, and when
| Region | Starts | Ends |
|---|---|---|
| United States, Canada | Second Sunday in March | First Sunday in November |
| UK, EU | Last Sunday in March | Last Sunday in October |
| Australia (southern states) | First Sunday in October | First Sunday in April |
| New Zealand | Last Sunday in September | First Sunday in April |
| Most of Asia, Africa, South America | No daylight saving at all | |
India, China, Japan, most of Africa and much of South America keep a single offset all year. India is also famously offset by 30 minutes (UTC+5:30), as are Iran, parts of Australia and Newfoundland — while Nepal is 45 minutes off at UTC+5:45.
Finding a slot that works
With participants spread widely, perfect overlap often doesn't exist. Some practical approaches:
- Rotate the pain. If someone must take an awkward hour, alternate who it is rather than always burdening the smallest group.
- Europe–Asia: European morning, Asian afternoon. Usually comfortable for both.
- Europe–US: European afternoon, US morning. The classic 15:00 London / 10:00 New York slot.
- US–Asia: genuinely hard. US evening against Asian morning is usually the least bad option.
- Consider not meeting. For a 15-way global sync, a written update often serves better than forcing half the participants awake at 05:00.
Writing times so nobody misreads them
- Use a calendar invitation wherever you can — it converts automatically and removes the problem entirely.
- Include the date. "3pm Tuesday" is ambiguous when it's already Wednesday somewhere.
- Quote UTC as the anchor, then local times in brackets.
- Use the 24-hour clock in writing. "7:00" versus "19:00" beats an am/pm typo.
- Avoid bare abbreviations. "CST" is US Central, China Standard and Cuba Standard time, and they are nine hours apart.
A note on how this works
Conversion uses the IANA time zone database built into your browser, the same source operating systems use. It knows historical and scheduled rule changes, so a date next year converts correctly even if a country has already legislated a change. Nothing is sent to a server.
Frequently asked questions
Does this handle daylight saving time?
Yes, automatically. It uses your browser's built-in IANA time zone database, so it knows that New York is UTC−5 in January and UTC−4 in July, and applies the correct offset for the specific date you pick. This is why choosing the actual meeting date matters — the difference between London and New York is normally 5 hours, but for a couple of weeks each spring and autumn it is 4.
Why do the clocks change on different dates in different countries?
Because each country legislates independently. The US moves in March and November, the EU and UK in late March and late October, and most of Asia and Africa do not observe it at all. Southern hemisphere countries shift in the opposite direction. For roughly three weeks a year the usual offsets between Europe and North America are simply wrong.
What are the shaded hours?
Working hours, 09:00 to 18:00 local time in each city. Columns where every city is inside that band are the slots that work for everyone. Rows shaded amber are outside working hours but still civilised; red means someone is being asked to join in the middle of the night.
What is UTC, and is it the same as GMT?
UTC is the modern time standard the world synchronises to. GMT is a time zone that happens to equal UTC in winter, but the UK shifts to UTC+1 in summer while UTC never changes. For scheduling, always write UTC rather than GMT — it removes the ambiguity.
How should I write a time in an invitation?
Include the UTC offset and the date: "Tuesday 14 April, 15:00 UTC (16:00 BST / 11:00 EDT)". Better still, send a calendar invitation — every client converts it to the recipient's local time automatically, which eliminates the whole problem.