EST to IST: Stop DST Breaking Meetings in 5 Minutes

Quick fix before you read on: If your standing meeting between New York and Bangalore was set up in January, it's already wrong by the second Monday of March — and nobody's calendar warned you.

You set up a recurring 9:00 AM ET / 7:30 PM IST sync back in February. Everyone showed up. It worked. Then March 10th hit, the US sprang forward, and suddenly your Bangalore team is logging in at 6:30 PM instead of 7:30 PM — or worse, your New York team is dialing in at 10:00 AM expecting everyone, only to find the India side hasn't arrived yet. The meeting didn't break. The time difference broke. And your calendar tool let it happen silently.

This is the single most common failure point for anyone managing recurring meetings between US Eastern Time and India Standard Time. The gap isn't fixed. It shifts twice a year — and only on one side. India doesn't observe daylight saving time at all, which means the IST to EST conversion you memorized in winter is dead wrong by spring.

Here's the pitfalls guide to getting this right, written for people who've already been burned once.

Pitfall #1: Assuming the time difference never changes

This is where it all starts going sideways. Most people remember that the US observes daylight saving time. Fewer people remember that India doesn't. Almost nobody remembers that this means the offset between the two changes by a full hour, twice a year.

Here are the real numbers:

• During US Eastern Standard Time (EST): IST is 10 hours 30 minutes ahead
• During US Eastern Daylight Time (EDT): IST is 9 hours 30 minutes ahead

That one-hour swing is the entire problem. If you scheduled a meeting at 9:00 AM EST in February, that's 7:30 PM IST. Come March 10th, 9:00 AM EDT is now 6:30 PM IST. The meeting time on your calendar didn't change. The offset did. Your India team is now joining an hour early — or they show up at 7:30 PM IST like they always have, and your US team has already been waiting since 10:00 AM EDT wondering where everyone is.

The fix

Never memorize a single offset. Always think in terms of "which season am I in right now?" If you're between the second Sunday in March and the first Sunday in November, the gap is 9.5 hours. Outside that window, it's 10.5 hours. Write it on a sticky note. Tattoo it. Whatever works.

Pitfall #2: Not knowing the exact DST transition dates

The US DST transitions don't happen on fixed calendar dates. They happen on nth Sunday of a month, which means the date shifts every year. If you're planning a recurring meeting for Q2 2025, you need to know exactly when the November transition falls — because that's when your meeting breaks again.

Here are the upcoming transitions you need to care about:

• Spring 2025: DST begins Sunday, March 9, 2025 at 2:00 AM EST → clocks jump to 3:00 AM EDT
• Fall 2025: DST ends Sunday, November 2, 2025 at 2:00 AM EDT → clocks fall back to 1:00 AM EST
• Spring 2026: DST begins Sunday, March 8, 2026
• Fall 2026: DST ends Sunday, November 1, 2026

Mark these in your calendar as all-day events titled "US-India meeting offset changes today". Not "DST starts." Not "spring forward." Specifically label what it means for your cross-timezone workflow. When that reminder fires, you know it's time to audit every recurring meeting on your plate.

Pitfall #3: Trusting calendar recurrence rules to handle it correctly

This one catches people off guard. You'd think that Google Calendar or Outlook, which clearly know about daylight saving time, would handle this automatically. Sometimes they do. Sometimes they don't. And the behavior depends on how the meeting was originally created.

Here's the problem: when you create a recurring meeting, the calendar stores the time in the creator's local timezone. If a US-based person creates a 9:00 AM ET recurring meeting, the calendar interprets that as "9:00 AM in America/New_York" — which means it will adjust for DST on the US side. The meeting stays at 9:00 AM ET year-round. But the IST equivalent shifts from 7:30 PM to 6:30 PM and back. The India participants see their meeting time jump around.

Conversely, if an India-based person creates the recurring meeting at 7:30 PM IST, that stays fixed year-round — but now the US participants see the meeting shift from 9:00 AM to 8:00 AM and back.

The fix

Decide upfront which side absorbs the shift. There's no universal right answer — it depends on your team composition and power dynamics. But someone has to move, and it should be a conscious decision, not an accident of who created the calendar invite.

If the majority of participants are in India, have the US side flex. If the meeting is US-led, have India flex. Document the decision somewhere visible so it doesn't become a source of quiet resentment six months in.

Pitfall #4: Setting up the meeting once and never revisiting it

The most common workflow failure isn't the initial setup — it's the lack of a maintenance routine. People set up a recurring meeting in January, it works great through February, breaks in March, gets patched ad hoc, works fine through summer, breaks again in November, and by then everyone's frustrated.

You need a biannual audit. Twice a year, in the week before each DST transition, review every recurring meeting on your calendar that involves US Eastern and IST participants. Check whether the meeting time still works for both sides. Confirm that the calendar invite is still sending the correct local time to each participant.

Concrete example

Say you manage a 12-person engineering team split between Boston and Hyderabad. You have three standing meetings:

• Monday sprint planning: 8:30 AM ET / 7:00 PM IST (winter) → 8:30 AM ET / 6:00 PM IST (summer)
• Wednesday mid-week sync: 10:00 AM ET / 8:30 PM IST (winter) → 10:00 AM ET / 7:30 PM IST (summer)
• Friday demo review: 11:30 AM ET / 10:00 PM IST (winter) → 11:30 AM ET / 9:00 PM IST (summer)

In summer, the Friday meeting ends at 9:00 PM IST for Bangalore. That's tolerable. But the Monday meeting now starts at 6:00 PM IST — right during dinner. That's the kind of thing you catch in a biannual review and fix by shifting the meeting 30 minutes. Without the review, you just lose attendance quality slowly until someone complains.

Pitfall #5: Using the wrong time zone converter for planning

Not every time zone converter handles DST the same way. Some tools show you the current offset, which is fine for scheduling a one-off meeting right now but useless for planning a recurring meeting three months out. If you're using a converter in February to plan a meeting that will run through April, you need a tool that lets you specify a future date and shows you the correct offset for that date.

When you're evaluating a time zone converter for this use case, look for three things:

• Date-specific conversion: Can you input a future date and get the correct offset, accounting for whether DST is in effect?
• Visual overlap display: Does it show you a timeline or heatmap of working hours overlap between ET and IST?
• DST transition markers: Does it flag dates where the offset changes?

If your converter just shows "IST is 10.5 hours ahead of EST" with no date context, it's setting you up to fail. The offset is only 10.5 hours for about 4.5 months of the year. The rest of the time it's 9.5 hours. A converter that doesn't distinguish between these is giving you a winter-only answer.

Pitfall #6: Forgetting about the "gap weeks" when other regions shift

Here's a sneaky one. If your meeting also includes participants in Europe — say, a London teammate joining your US-India sync — you now have a three-way time zone problem, and the transitions don't align. The US and Europe shift on different dates, creating a 2-3 week window where the offsets are temporarily misaligned.

In 2025, for example:

• US springs forward: March 9, 2025
• EU springs forward: March 30, 2025

Between March 9 and March 30, the US is on EDT but the UK is still on GMT. That 3-week window changes your London participant's meeting time relative to both the US and India. If you have any European participants on your recurring meeting, you now have four transition points per year to manage, not two.

The fix

Maintain a simple transition calendar that includes all relevant regions. For a US-India meeting with European participants, you need:

• US DST start (March)
• EU DST start (late March)
• US DST end (November)
• EU DST end (late October)

That's four audit points. Each one is a 5-minute check. Skip them and you'll have a confused London teammate showing up an hour off for three weeks every spring and fall.

Pitfall #7: Not documenting the meeting time in both zones

This sounds trivial, but it's the highest-leverage fix you can make. Every recurring meeting invite should state the time in both time zones, with the current season's offset, in the meeting title or description.

Bad title: "Weekly sync"

Good title: "Weekly sync — 9:00 AM ET / 6:30 PM IST (summer) — shifts to 7:30 PM IST after Nov 2"

This does two things. First, it gives every participant an immediate reference point without needing to open a converter. Second, it surfaces the DST shift explicitly — nobody can claim they didn't know the time was going to change. The meeting title itself becomes a reminder system.

Update the title twice a year after each transition. Yes, it's manual. Yes, it takes 30 seconds. It will save you a missed meeting and an awkward conversation with a senior stakeholder eventually.

The bottom line

Scheduling recurring meetings between US Eastern and India Standard Time isn't hard once you internalize one fact: the offset is seasonal, not permanent. Every system — your memory, your calendar, your converter — needs to account for the fact that IST is 9.5 hours ahead of ET from March to November, and 10.5 hours ahead the rest of the year. Build your workflow around that reality, audit twice a year, document the times in both zones, and you'll stop losing meetings to daylight saving transitions.