No upload, 100% local, no account

Article

Scheduling meetings across time zones

Picking a meeting time that works for people in three cities sounds simple until the clocks change and everyone shows up an hour late. This guide walks through the mechanics of UTC offsets, explains why daylight saving time is the main source of scheduling errors, and shows a repeatable method for finding a window that falls in business hours for all participants.

UTC and Offsets: The Foundation

Coordinated Universal Time (UTC) is the common reference point for all civil time. Every time zone is expressed as UTC plus or minus a number of hours and minutes. New York in winter is UTC-5, Paris in winter is UTC+1, Tokyo is UTC+9. When you write a time in UTC, anyone anywhere can convert it to their local clock without guessing. Most offsets are whole hours, but not all. India runs at UTC+5:30, adding a half-hour that often surprises people. Nepal goes further at UTC+5:45, a 45-minute offset that exists for historical and political reasons. Parts of Australia use UTC+9:30 and UTC+10:30. Whenever you see a time zone listed as a whole-hour offset, check: there may be a sub-hour zone in the same region. The practical rule is to anchor every calendar invite in UTC. Local times change twice a year in many countries; UTC does not.

Diagram showing UTC at centre with offset arrows pointing to city clocks on different continents, including a +5:30 arrow for India and a +5:45 arrow for Nepal

Daylight Saving Time: Why Offsets Shift

Daylight saving time (DST) advances clocks by one hour in spring and returns them in autumn, which shifts a country's UTC offset by one hour for several months. The United States moves clocks on the second Sunday of March and the first Sunday of November. Most of Europe moves on the last Sunday of March and the last Sunday of October. Australia, being in the southern hemisphere, shifts in October and April. Many countries, including Japan, India, China, and most of Africa and South-East Asia, observe no DST at all. The result is a period of two to three weeks in March and October when the difference between two cities is not the number you have memorised. New York to London is normally five hours apart; for those two to three weeks in March it is four, because the US has already moved its clocks and the UK has not yet. This is the main source of scheduling errors in international calendars. The only safe strategy is to verify the offset on the specific date of the meeting, not the offset you remember from last month.

Finding an Overlapping Window

Write out the UTC offset for each participant's location on the day of the meeting. Then draw a row for each city, marking which UTC hours correspond to that city's 09:00 to 18:00 window. The intersection of all rows is your candidate slot. A concrete example: New York (UTC-5 in winter), London (UTC+0), and Mumbai (UTC+5:30). London 09:00 is UTC 09:00, New York 09:00 is UTC 14:00, Mumbai 18:00 is UTC 12:30. The windows do not intersect across all three cities: London and New York share UTC 14:00 to 17:00 (London 14:00-17:00, New York 09:00-12:00), but Mumbai's business day has already ended at UTC 12:30, well before that window opens. Someone will have to accept a slot outside standard hours. This kind of calculation is exactly what the timezone-difference tool on this site handles. Feed it two cities and a date and it shows the offset and whether that date falls in a DST transition window.

Grid of three rows labelled New York, London, and Mumbai, with shaded business-hours bands showing where the overlap window falls across a UTC timeline

Practical Habits for Recurring Meetings

Name the time zone in every invitation. Writing "15:00" is ambiguous; writing "15:00 UTC" or "15:00 CET (UTC+1)" removes the guesswork. Calendar applications translate this to each recipient's local time, but only if the zone is explicit. For a one-off meeting, verify the UTC offset for the specific date on the timezone-converter tool before sending the invite. For a recurring weekly meeting, check what happens at each DST transition date. A meeting fixed at "10:00 New York time" will shift by one hour relative to London participants twice a year. Either accept that shift and notify participants in advance, or fix the meeting in UTC and let everyone's calendar convert it locally. A simple convention used by many distributed teams: schedule everything in UTC, include local equivalents for the two or three most represented zones in the invite body, and add a calendar note two weeks before each DST transition reminding participants that the local time will change. The world-clock tool lets you check several cities at once against the current UTC time, which is useful for a quick sanity check before sending.

Doing It Locally, in the Browser

The three tools backing this article run entirely in your browser. No time data, no city names, no schedule details leave your device. The timezone-converter tool takes a date, a time, and a source zone and converts it to one or more target zones. It accounts for DST on the date you specify, so the offset it shows reflects the actual offset on that day, not the standard offset for the zone. The world-clock tool displays the current time in multiple cities side by side. This is the fastest way to answer "what time is it in Singapore right now" without opening a search engine. The timezone-difference tool calculates the hour difference between two zones on a given date. Because it is date-aware, it correctly handles the transition weeks when the two zones have not both shifted yet. All three tools work offline once the page has loaded. The calculations use the IANA time zone database bundled with your browser, so the DST rules are as current as your browser version.

Tools in this article

Frequently asked questions

Why does the offset between two cities change in March even though neither city changed its time zone?

They changed their clocks on different dates. When one country applies its DST shift and the other has not yet, the difference between them shrinks or grows by one hour for the days in between. This resolves once both countries have made their transition.

India is at UTC+5:30. Does it observe daylight saving time?

No. India has not observed DST since 1945. The UTC+5:30 offset is constant throughout the year. Nepal, at UTC+5:45, also does not observe DST. This makes scheduling with South Asian participants more predictable than scheduling with European or North American ones.

Is it better to send a meeting invite in UTC or in the organiser's local time?

UTC is safer for international meetings. Most calendar applications display the invite in the recipient's local time if the source zone is stated, and UTC never shifts. If you send an invite in a DST-observing zone such as Eastern Time, recipients in zones that shift on a different date may see the wrong local time in the weeks around a transition.