Working Across New York and Mumbai
New York runs on Eastern Time and Mumbai runs on India Standard Time, which means the gap between them is never a clean round number. India does not observe daylight saving time, and New York does, so the offset swings between 9 hours 30 minutes and 10 hours 30 minutes depending on the season. That half-hour offset is the first thing that catches people off guard when they are trying to coordinate anything between these two cities. The math is straightforward once you lock down which period you are in. When New York is on Eastern Standard Time, which runs from the first Sunday in November through the second Sunday in March, Mumbai is exactly 10 hours and 30 minutes ahead. When New York switches to Eastern Daylight Time for the rest of the year, the gap shrinks to 9 hours and 30 minutes. Mumbai stays at UTC +5:30 the entire time. New York moves between UTC -5 and UTC -4. I used to manage deployments for a platform that served customers in both regions. We built our scheduling system around the fact that the offset changed twice a year, but we treated it as a single moving target instead of two separate zones. Here is how that actually works in practice. Pick a time in New York and add the correct offset to get Mumbai time. If it is 9:00 AM on a Tuesday in New York during DST, you add 9 hours and 30 minutes and get 6:30 PM the same day in Mumbai. If it is 9:00 AM during EST, you add 10 hours and 30 minutes and get 7:30 PM in Mumbai. The day can stay the same or flip, depending on what hour you start from.
The part nobody warns you about is the overlap window, or lack of one. There is barely any time where both cities are in normal business hours on the same day. If you schedule a call at 10:00 AM on a Wednesday in New York during DST, that is 7:30 PM in Mumbai. Most people in Mumbai are already off work. If you push it to 7:00 AM New York time, that is 4:30 PM in Mumbai, which is reasonable for them but brutal for the New York side. The sweet spot, if you can call it that, is roughly 7:00 AM to 8:00 AM New York time, which lands at 4:30 PM to 5:30 PM Mumbai time. Even then, someone is sacrificing their morning. I ran into a real problem once where a cron job was set to fire at 3:00 AM New York time every day, and the expectation was that it would align with a cleanup window in Mumbai. During DST, 3:00 AM New York was 12:30 PM Mumbai, which was fine. After the clock fell back in November, that same job fired at 3:00 AM New York, which was now 1:30 PM Mumbai instead of noon. The downstream pipeline choked because a reporting batch had already started at 1:00 PM India time and the new data landed on top of it. We lost about 40 minutes of clean processing that day. The workaround was simple in hindsight: we stopped using local time strings in the job config and switched everything to UTC. The job stored its schedule as 08:00 UTC year-round, which mapped cleanly to both sides without any seasonal drift. It took us about an hour to audit the configs and re-run the failed jobs manually. If you need a quick conversion without pulling up a world clock widget, memorize this. Add 10 hours to the New York time, then add 30 minutes. If you are during DST, subtract one hour from that total. That gives you Mumbai time on the same calendar day for most reasonable business hours. The only edge case where the day flips is when you convert late-night New York hours, which land early morning the next day in Mumbai anyway.
There are tools that handle this automatically. Google will give you the answer if you type something like 9 AM New York to Mumbai. Many calendar apps let you add a second time zone to an event and show both offsets live. If you want something programmatic, libraries like moment-timezone or the built-in Intl.DateTimeFormat in modern JavaScript handle the DST transitions without you having to hard-code any dates. In Python, pytz or the newer zoneinfo module does the same thing. The key is to store everything in UTC internally and only format to local time at the edges of your system. One counter-intuitive thing that trips people up is assuming the gap is symmetric. It is not. A meeting at 2:00 PM Mumbai time equals 3:30 AM New York time during DST, which is useless. But a meeting at 10:00 AM New York time equals 7:30 PM Mumbai time, which is also pretty useless. The asymmetry comes from the half-hour offset combined with the fact that neither city shares a conventional business-hour window. You cannot find a time that is comfortable for both sides. You can only find a time that is less terrible for one side than the other. Another thing beginners miss is that India Standard Time is offset by a half hour from the hour, which breaks a lot of naive scheduling logic. If your system assumes hour-long blocks aligned to the clock face, 5:30 PM stops looking like a clean end-of-day boundary. Scheduling tools that only display whole hours will quietly round or truncate, and you will not notice until someone shows up five minutes late or early. Always verify the output of any automated scheduler against a manual conversion at least once before you trust it at scale.
Get the Full Details
The biggest limitation here is human. No matter how clean your UTC storage is or how good your libraries are, the overlap problem does not go away. If your team is permanently split between New York and Mumbai, you will always have someone working outside their preferred hours. The best I have seen teams handle it is by alternating the inconvenient slot week to week, or by accepting that certain ceremonies like sprint planning happen at 7:30 AM New York time and rotating the discomfort so it does not always land on the same people. Some companies hire a dedicated afternoon-only role in New York whose sole job is to be available during Mumbai business hours, which is expensive but honest about the tradeoff. If you just need to check a one-off conversion, use a site like timeanddate.com or ask your phone's world clock app. If you are building a system that touches both regions, normalize to UTC everywhere and never let local time strings leak into your database or your job configurations. The half-hour offset and the biannual DST shift in New York will reward carelessness with silent misalignment, and those misalignments are much harder to debug after they have already caused a broken deployment or a missed SLA. The bottom line is that the New York to Mumbai gap is either 9 hours 30 minutes or 10 hours 30 minutes, it changes twice a year, and there is no comfortable overlap window. Everything else is just mitigation.
