How to schedule meetings across time zones without confusion

To schedule meetings across time zones without confusion, tie every meeting to a date and a named time zone, such as America/New_York. Then confirm the local date and time for each person, and check again around daylight saving changes. That's what stops the classic one-hour mix-up.

Here's that mix-up in action. You agree to meet a New York client at 9 in the morning. On 20 October 2026, that's 18:30 in India. On 10 November, the same New York time is 19:30 in India. Nobody moved the meeting. US clocks went back on 1 November, and India's clocks didn't.^[5]

Three time zone settings to get right

Most time zone mix-ups come from three settings that do different jobs.

• The host's time zone decides which hours you offer.
• The invitee's time zone decides how those hours are shown to them.
• Each person's calendar time zone decides how the booked meeting appears afterward.

Changing one of these doesn't change the others, so check each on its own when something looks off.

Google Calendar lets you set a time zone on each event and shows it in the viewer's own calendar time zone. You can also add a secondary time zone to your calendar view. That makes it easy to compare working hours without converting in your head.^[1]

When you plan, use zone names like Asia/Kolkata, America/New_York and America/Los_Angeles. They come from the IANA time zone database, which stores each region's offset and daylight saving rules. A zone name follows those rules through the year, while a fixed offset like UTC-5 never changes. Your software needs current time zone data to apply them.^[2]

When you write to clients, put the city next to the zone name. New York (America/New_York) is easier to check than EST, which many people use all year even though New York runs on EDT for most of it. Also say morning or evening, or stick to the 24-hour clock.

India–US meeting times for specific dates

The examples below use real 2026 dates, checked against the IANA rules and NIST's 2026 daylight saving dates. India stays at UTC+05:30 all year. New York and Los Angeles move back one hour when US daylight saving ends on 1 November 2026, so the gap to India grows by an hour.^[3][4][5]

Both dates are Tuesdays. Watch out for calls that cross midnight. A 16:00 Los Angeles call on 20 October is 04:30 in India on Wednesday, 21 October. Always check the date as well as the hour.

You can also fix the time on the Indian side. An 18:30 India call is 09:00 in New York on 20 October but 08:00 on 10 November. The right answer depends on whose local time you agreed to keep.

Find an overlap people can actually accept

Ask people which hours work for them before you pick the overlap. A free slot at 06:00 isn't a reasonable invite just because it's open. Think about the meeting length, prep time, and things like a commute or school run that make an hour hard.

For example, an Indian consultant offers international calls from 18:30 to 20:00 India time. On 20 October that's 09:00–10:30 in New York. On 10 November it's 08:00–09:30. When the gap changes, ask the client whether the window still suits them.

A Los Angeles client is harder. Their 09:00 is 21:30 or 22:30 in India, depending on the date. Don't open your whole evening just because a converter can show it. Offer a short agreed window, rotate awkward times for recurring team calls, or send an update by email or recorded video when nobody needs to be live.

Check daylight saving before recurring calls

In 2026, US daylight saving runs from 8 March to 1 November, according to NIST. Some places, such as Hawaii and most of Arizona, don't observe it at all. So picking a country isn't enough. Choose each person's actual time zone.^[5]

For a recurring meeting, agree on the anchor, such as 09:00 New York every Tuesday, rather than the same time for everyone. A series tied to one city's clock will land at a different hour elsewhere when the offsets change. If you book series of meetings, see how recurring scheduling in Caletus works.

Check the meetings just before and just after the clock change. Open the actual invite instead of trusting a screenshot of the first meeting. If the new time doesn't work, agree on a change, update the series, and tell people which dates are moving.

Avoid putting an important call in the early-morning hour when clocks change. In the US that happens at 2:00 am local time. When clocks go back, one local hour happens twice. When they go forward, some local times don't exist at all. A calendar invite with a proper time zone is much safer than a date and time typed into a chat.^[5]

How Caletus shows local times to invitees

Caletus detects each invitee's time zone and shows your open slots in their local time, while you keep your schedule in yours. Automatic time zone detection is included on every plan, including Free. The availability management page shows how your hours and time zones work together.^[6]

Test it once before you share the link. Set the host's time zone on purpose, then open the booking page on a second device set to the invitee's time zone. A private browser window doesn't change your device's time zone, so note the zone you actually tested with.

Make sure the visitor can see which time zone the page is showing before they pick a time. If they can change the zone by hand, test that with the same date too. The booking should still land at the same moment.

When someone says the time is wrong, ask where they saw it: the booking page, the email, their calendar or a reminder. Note the time zone shown there. Fixing a device setting may solve a display problem, while editing the booking could move a meeting that was right all along.

What happens to your meetings when you travel

Before a trip, decide whether your bookable hours stay on home time or switch to local time at your destination. Both are fine, but they're different choices. If you change your schedule's time zone, 09:00 on your booking page becomes a different moment for clients.

Google Calendar can show your calendar in your local time zone while you travel. That only changes the display. It doesn't reschedule a confirmed call, so review existing meetings, travel blocks and new-booking hours separately.^[1]

Set temporary hours for the travel dates only. A date override, like the ones in this guide to holiday availability, is one way to do it. Check the first day away and the first day back, and don't let an untested automatic adjustment decide when clients can book you.

Test what the invitee sees, start to finish

1. 1Note the host's time zone and the test device's time zone.
2. 2Open the booking page and check the date, the time zone shown, the meeting length and whether it's morning or evening.
3. 3Book one of the examples from the table above and compare the confirmation with the time you expected.
4. 4Check the invitee's calendar event, the host's calendar event, the confirmation email and any reminder.
5. 5Repeat for a date after a daylight saving change, and for a time that crosses midnight for one person.
6. 6Reschedule the test booking and check both local times again. Delete the test bookings when you're done.

For the first example, the shared moment is 20 October 2026 at 13:00 UTC. A clear confirmation could read: "Confirmed: Tuesday 20 October, 09:00 New York / 18:30 India. 30 minutes. Your calendar invite shows your local time." Add the joining link and a way to reschedule. For more wording ideas, see these appointment confirmation email templates.

Treat that wording as an example to adapt. Whether a confirmation can show both time zones automatically depends on the template fields your scheduling tool offers.

The final check is simple. Can the host and the invitee each tell you, without help, when the meeting starts? If both answers match, you've removed the uncertainty behind most international scheduling mix-ups.

• international meeting scheduling
• India US meeting times
• daylight saving meeting scheduling
• booking page time zones