EST to IST Converter
Interpreted in the "From" timezone
US Eastern-to-India scheduling is one of the more genuinely difficult cross-timezone problems in distributed work, not because the math is hard but because the two working-hours windows barely touch. A standard 9-to-5 in New York and a standard 9-to-5 in Bangalore or Mumbai don’t overlap at all under normal circumstances — by the time the US East Coast starts its day, India’s workday is already winding down or over, and by the time India starts its day, the US East Coast is typically asleep. Every meeting between the two sides is a negotiated tradeoff, not a natural overlap, which is exactly why getting the conversion right (and understanding how it shifts across the year) matters more here than for same-continent pairs.
The gap itself moves depending on the season, for a reason specific to this pair: India Standard Time never changes (fixed UTC+5:30 year-round), but America/New_York does — UTC-5 in winter (EST), UTC-4 in summer (EDT) — so the total gap between the two is 10.5 hours in US winter and 9.5 hours in US summer, a full hour of drift that has nothing to do with India’s side of the equation at all. A meeting time that worked in January can land an hour differently by July if it was pinned to a fixed India-side clock time without accounting for which side of the US DST boundary the date falls on.
Working through a concrete case: 9:00 AM Eastern (EDT, since it’s July) on July 30, 2026 converts to 6:30 PM IST — early evening in India, arguably the more workable end of a difficult range, since it asks the US side for a reasonably normal morning start rather than the India side for a very early or very late slot. Shifting the same meeting to a typical India morning (9 AM IST) would instead land around 11:30 PM the previous day on the US East Coast — illustrating why “early US morning, India evening” tends to be the practical compromise distributed US-India teams converge on.
Converting Eastern time to India Standard Time programmatically
JavaScript, via the round-trip technique needed whenever the starting point is a wall-clock time in a specific zone:
function zonedTimeToUtc(year, month, day, hour, minute, timeZone) {
const naiveUtc = Date.UTC(year, month - 1, day, hour, minute);
const parts = new Intl.DateTimeFormat("en-US", {
timeZone, year: "numeric", month: "2-digit", day: "2-digit",
hour: "2-digit", minute: "2-digit", hour12: false,
}).formatToParts(new Date(naiveUtc));
const get = (t) => Number(parts.find((p) => p.type === t)?.value ?? 0);
const readBack = Date.UTC(get("year"), get("month") - 1, get("day"), get("hour") % 24, get("minute"));
return new Date(naiveUtc - (readBack - naiveUtc));
}
const utcInstant = zonedTimeToUtc(2026, 7, 30, 9, 0, "America/New_York");
console.log(new Intl.DateTimeFormat("en-US", {
timeZone: "Asia/Kolkata", timeStyle: "short",
}).format(utcInstant));
// "6:30 PM"
Python, via zoneinfo:
from datetime import datetime
from zoneinfo import ZoneInfo
eastern_time = datetime(2026, 7, 30, 9, 0, tzinfo=ZoneInfo("America/New_York"))
ist_time = eastern_time.astimezone(ZoneInfo("Asia/Kolkata"))
print(ist_time)
# 2026-07-30 18:30:00+05:30Frequently asked questions
What's the best time to schedule a meeting between US Eastern and India teams?
Why is the US East Coast to India gap so much larger than the West Coast to India gap?
Does the gap between Eastern time and India change with daylight saving?
Why is the offset 9.5 or 10.5 hours instead of a round number?
Is the date/time I enter sent to a server?
Related Timezone Converter pages
Looking for a different pair or algorithm? Here are the other specific versions, plus the general tool for everything else: