Time Zone Meeting Planner

How to find a meeting time that works across time zones

Enter the meeting in your own time zone, add everyone else’s, and read off their local times, who is inside working hours and which start times on that day are fairest. The offsets are the ones in force on the meeting date, so a call booked during a daylight-saving change comes out right.

• Meeting date and Start time: as your own calendar shows them.
• Your time zone: type a city, a country or an IANA name such as Europe/Paris and pick from the list. Nearby big cities work too: Bengaluru and San Francisco find India and US Pacific time. Use my time zone fills in the zone your browser reports, which is also first in the list before you type.
• Meeting length: minutes or hours and minutes, such as 45, 1:30 or 1h 30m.
• Working hours: leave them blank for 09:00–17:00. An end earlier than the start, such as 22:00–06:00, is read as an overnight shift.
• Other time zones: one row per person or office, up to 10, each with its own working hours.

Results change as you type. The Try buttons load the cases worked through on this page, from a winter US–India call to a start time that falls in a clock change.

Worked example: San Francisco, Berlin and Bengaluru on October 29, 2026

A 1-hour call starts at 08:00 in San Francisco on Thursday, October 29, 2026. One colleague is in Berlin, on 09:00–17:00. The other works 10:00–19:00 in Bengaluru.

1. San Francisco to UTC. Pacific time is still on PDT, UTC−07:00, because US clocks go back only on November 1. So 08:00 − (−07:00) = 15:00 UTC.
2. Berlin. Berlin left summer time on October 25 (per the tz data) and is on CET, UTC+01:00: 15:00 + 01:00 = 16:00. The call runs 16:00–17:00, inside working hours.
3. Bengaluru. India is on IST, UTC+05:30, all year: 15:00 + 05:30 = 20:30. The call ends at 21:30, which is 2 h 30 min after the 19:00 close.
4. San Francisco itself. 08:00 is 1 h before a 09:00 start.
5. Result: 1 of 3 inside working hours, with 3 h 30 min outside working hours in total.

The fairest start that day is 07:15 San Francisco = 15:15 Berlin = 19:45 Bengaluru. The total is still 3 h 30 min, but it is split evenly, 1 h 45 min early in San Francisco and 1 h 45 min late in Bengaluru, instead of 2 h 30 min falling on one person.

The planner also warns that this is an odd week. Berlin is 8 hours ahead of San Francisco on October 29 but 9 hours ahead a week before and a week after, because Europe and the US change their clocks on different Sundays. If the call repeats weekly at 08:00 San Francisco time, from November 5 it lands at 17:00 in Berlin and 21:30 in Bengaluru.

How to read the overlap grid (working hours, early, late)

• Inside working hours is the headline: how many of the people or offices have the whole meeting within their hours. The line under it can be copied as it is into a chat or an invite.
• Local times gives one card per place: the local start and end, the date with a +1 day or −1 day badge when it differs from yours, the UTC offset, the tz abbreviation and whether daylight saving time is in effect.
• ● inside, ◐ partly outside, ○ outside. Each status has a symbol as well as a color, and screen readers hear it in words, so the tables read the same in print, in high-contrast modes and aloud.
• Outside working hours measures how far the meeting reaches past the edge of someone’s working day. A 07:00–08:00 meeting against 09:00–17:00 is 2 h outside, because that person has to start 2 hours early. A meeting that crosses the start or end of the day is only partly outside.
• Every hour lists the whole day in your time zone, an hour apart, with everyone’s local time. Select any start time in either table to use it.
• How this was calculated shows the offset arithmetic, so you can check any row by hand.

What if working hours don’t overlap?

The Fairest start times table then ranks start times, every 15 minutes across the day, by the total time outside working hours, then by the longest stretch for one person. Between two offices whose hours never overlap, that total can’t go below a fixed amount. In the worked example, Bengaluru’s 19:00 close is 13:30 UTC and San Francisco’s 09:00 open is 16:00 UTC. That leaves a 2 h 30 min gap, so any 1-hour call between them costs 3 h 30 min in total. The only choice is who carries it.

To share the load, save one start time with Save for comparison, change the time and save again. Each saved scenario shows its change from the first. Moving the worked example from 08:00 to 07:15 shows “-45 min (better)” for the longest stretch for one person. Rotating between an early slot for one side and a late slot for the other is a common fix. A shorter meeting also shrinks every late or early stretch minute for minute.

Does the planner handle daylight saving time?

Yes, in three ways.

• Offsets on the meeting date. Each zone’s offset is looked up for the actual meeting instant, not today’s.
• Changes near the meeting. If any zone changes its clocks within 7 days either side of the meeting, a notice names the place, the date and the old and new offsets. It also says when the gap to your time zone is different a week earlier or later.
• Skipped and repeated times. A start time that doesn’t exist, such as 02:30 in New York on March 14, 2027, or one that happens twice, such as 02:30 in Berlin on October 25, 2026, brings up a question with both real times. For the skipped time the default is 03:30 EDT, the reading calendar files use; 01:30 EST is the other choice. For the repeated time the default is the first 02:30 (CEST, 20:30 on Saturday in New York) and the second is an hour later (CET, 21:30 in New York).

Lord Howe Island moves its clocks by 30 minutes rather than an hour, and the planner follows that too.

Why city names work better than abbreviations like IST or CST

The same letters mean different clocks. IST is India, Israel and Irish summer time; CST is central North America, China and Cuba. EST is also used loosely for Eastern Time, although New York is on EDT from the second Sunday in March to the first Sunday in November. Type an abbreviation into a time-zone field and the planner lists the places it can mean, then asks you to pick one, instead of guessing. An offset such as UTC+5:30 works the same way: it lists the places on it, Kolkata and Colombo. A city or IANA name carries the whole set of rules, including future clock changes the database already knows about.

Scheduling a recurring meeting across a DST change

The Weekly meeting check repeats your start time for 12 weeks in your own time zone and marks every place whose local time moves. In the worked example, all 11 weeks after October 29 move for Berlin and Bengaluru, because San Francisco falls back on November 1. A US–India call shows the same thing in spring. 09:00 in New York is 19:30 in Kolkata until March 9, 2027 and 18:30 from March 16.

Say in the invite which city’s clock the series follows, such as “Thursdays 08:00 San Francisco time”. Everyone else then knows their slot will move with it.

Adding the meeting to your calendar (.ics)

Add to calendar (.ics) saves a calendar file with the meeting’s start and end in UTC, so Outlook, Google Calendar and Apple Calendar each show it in their owner’s own time zone. The file holds a single meeting. For a weekly series, create the repeat in your own calendar app from your own time zone, then check the weekly table for how the others move. Share link gives a web address with the date, time and zones in it; the site doesn’t store it.

Assumptions and limitations

• Offsets come from your browser’s copy of the tz database. Governments change the rules, sometimes with only weeks of notice, and a browser that hasn’t updated yet still shows the old rules. Recheck meetings months ahead as the date approaches.
• Every day counts as a working day. The planner flags a Saturday or Sunday start, but it doesn’t know about public holidays or weekends that fall on other days.
• Working hours are one window per day. Lunch breaks and split shifts aren’t modeled.
• Dates from 1970 to 2200 are accepted. Rules for far-future dates are today’s predictions.
• Abbreviations are the tz database’s own. Where it has none, as for Dubai or Singapore, the page shows the offset, such as UTC+04:00. It also shows only the offset for a past year in which a place kept different clocks from today’s, because the same offset once had another name there (Anchorage’s UTC−09:00 was AHDT in the summer of 1981, not today’s AKST).

Common mistakes

• Checking the difference today instead of on the meeting date. New York is 5 hours behind London most of the year, but only 4 during the weeks when one has changed its clocks and the other hasn’t.
• Forgetting the other date. A Tuesday 09:00 meeting in Auckland on November 17, 2026 is Monday 12:00 in Los Angeles and Monday 10:00 in Honolulu. The +1 day and −1 day badges point this out.
• Rounding 30- and 45-minute offsets to the hour. Kathmandu is 15 minutes ahead of Kolkata, not level with it and not an hour ahead.
• Booking inside a clock change. A start in the skipped or repeated hour means different things in different apps. Move it outside that hour, or pick the reading you mean when the planner asks.
• Assuming a weekly slot never moves. Different regions switch on different Sundays and some never switch at all, so check the weekly table before sending a series.