How to schedule between the US and India

April 6, 2026 · Updated May 7, 2026 · TimeZoneMeet editorial team

US ↔ India is one of the most demanding scheduling problems in distributed work, and most teams that handle it badly are making the same handful of mistakes. The two underlying difficulties are simple to state. First, the offset is large: somewhere between 9.5 and 13.5 hours depending on which US time zone is involved and what season it is. Second, India observes a half-hour offset from UTC. India Standard Time (IST) is UTC+5:30 year-round, with no DST. If you have ever quietly rounded "12.5 hours" to 12 in your head, you have already shipped at least one calendar invite that arrived 30 minutes off.

This guide breaks the problem into pieces and gives you a repeatable process for every US–India meeting your team has ever held. We will use San Francisco, New York, and Bengaluru as the example cities throughout, since they cover most real situations.

Know your offsets cold

The first step is to internalize the four offset combinations that matter. The US ↔ India gap shifts by an hour twice a year because the US observes DST and India does not. The full table for 2026:

Period	SF ↔ Bengaluru	NY ↔ Bengaluru
Jan 1 – Mar 7 (US standard)	13:30 hours (IST ahead)	10:30 hours
Mar 8 – Nov 1 (US daylight)	12:30 hours	9:30 hours
Nov 2 – Dec 31 (US standard)	13:30 hours	10:30 hours

Notice that India's offset is unchanged in every row — what moves is the US side. If you mentally anchor on "Bengaluru is 12:30 ahead of San Francisco," that is true from March through October but wrong by an hour in winter. The defensive habit is to look up the current offset every time, not to commit any single number to memory.

The three usable windows

For US–India, almost every viable meeting time falls into one of three windows. Each has a different distribution of pain.

Window A: US early morning, India evening

This is usually the most sustainable choice. From mid-March through October, 07:00 PT in San Francisco is 19:30 IST in Bengaluru — late but not unreasonable. 07:00 ET in New York is 16:30 IST, comfortably inside the Indian working day. The cost is a slightly early start for the US side, which most engineers will accept once or twice a week. This is the standard slot for a US–India daily standup.

The trap is that the same wall-clock time becomes worse in winter: 07:00 PT in January is 20:30 IST, which pushes into family-evening territory. If you keep this slot year-round, plan for either a winter-time shift or an explicit acknowledgement that the India side absorbs the extra half hour for three months.

Window B: US morning, India night

09:00 or 10:00 ET works well for sales calls and customer escalations where the US side needs to be sharp and the India side can join from home. The cost is real: 09:00 ET = 18:30 IST in summer, 19:30 IST in winter. Acceptable for a one-off, painful as a recurring slot. We do not recommend this window for engineering standups; it consumes the India side's evening too consistently.

Window C: India morning, US late evening

09:00 IST in Bengaluru is 23:30 PT (the previous calendar day) in San Francisco during US daylight time, or 22:30 PT during US standard time. This is unambiguously bad for the US side and should only be used when (a) the US side is consciously absorbing pain in a rotation, or (b) the meeting has only India-based decision-makers and a single US observer. Window C is most useful as the alternating slot in a fairness rotation: if you usually meet in Window A, the alternate week's slot lives here.

The half-hour mistake (and how to never make it)

The most common US–India scheduling failure is what we call the half-hour mistake. Someone proposes "9am Tuesday in San Francisco" and the recipient writes back "21:00 IST works." But 09:00 PT in summer is 21:30 IST, not 21:00. The 30-minute slip slides the meeting into someone's bedtime, or — worse — silently misaligns calendars when both sides type the wrong end of the half hour into their tools.

The fix is mechanical. Always quote both ends explicitly: "Tuesday May 12 at 09:00 in San Francisco (which is 21:30 in Bengaluru)." Never round 5:30 to 5:00 or 6:00 in your head. Use TimeZoneMeet's Schedule tool, which prints both sides' wall-clock times to the minute, or if you are doing the math manually, force yourself to write down the colon-30 explicitly.

Recurring meetings: the DST drift problem

Because India does not observe DST, every US–India recurring meeting drifts by one hour twice a year. A standup at 07:00 PT / 19:30 IST in February becomes 07:00 PT / 18:30 IST on March 8, when the US springs forward. Whether that is good or bad depends on whose calendar stored the original meeting:

Stored in US local time (most common with Google Calendar when the organizer is in the US): the meeting stays at 07:00 PT, and the India side sees it shift from 19:30 to 18:30 IST.
Stored in India local time: the meeting stays at 19:30 IST, and the US side sees it shift from 07:00 to 08:00 PT.
Stored in UTC: both sides see the meeting move on their wall clocks.

None of these is wrong, but the right answer depends on which side you are optimizing for. We have a longer treatment in DST and meeting planning; for US–India specifically, the recommended pattern is to store the recurring series in the time zone of whichever side is more sensitive to a wall-clock shift — usually the side that schedules around it (school pickups, gym slots, commute windows).

What to write in the invite

The safest invite text for US–India is a three-line block in the meeting description:

Tuesday May 12, 2026
07:00 PT (San Francisco) / 10:00 ET (New York)
19:30 IST (Bengaluru)
14:00 UTC

Four pieces of information on three lines: the date, the US zones with cities, the India zone with city, and the UTC anchor. Anyone reading this has no excuse for showing up late. If you only have room for one line, prefer the city-named version with both ends: "Tue 07:00 in San Francisco / 19:30 in Bengaluru".

Common mistakes

Treating IST as UTC+5. It is UTC+5:30. Always.
Using "IST" without context. It also means Irish Standard Time (UTC+1) for some audiences. Write "Bengaluru" or "Asia/Kolkata" instead.
Memorizing a single offset. The US side moves twice a year; your number is wrong half the time.
One-time slots that become recurring by default. Whoever clicks "make recurring" inherits all the future DST drift problems.
Treating Window C as fair. 23:30 PT is not "evening" — it is bedtime, and a recurring meeting at that time will produce a quiet attrition signal.

Verification before you send

Look up each city in TimeZoneMeet to confirm the current local time, in case offsets have shifted recently.
Run the proposed slot through Schedule with both cities and confirm the wall-clock times match what you intend.
If the slot is recurring, decide explicitly whose time zone the series is stored in, and document that in the meeting description.
For meetings with multiple India-side cities (Mumbai, Delhi, Bengaluru, Chennai), note that they all share IST — there is no internal-India offset problem.