What hours let a remote team in Mountain Time work with both coasts?
A 10 AM MT call is 12 PM Eastern, 11 AM Central, and 9 AM Pacific. A 3 PM MT call is 5 PM Eastern, 4 PM Central, and 2 PM Pacific. The window between 10 AM and 3 PM MT covers standard business hours in every US zone without forcing anyone to start before 7 AM or stay past 6 PM.
The common error is scheduling a call at 8 AM MT because it is 10 AM Eastern. That works for the East Coast but forces Pacific teams to join at 7 AM. Do that twice a week and you lose your California colleagues. The reverse mistake is scheduling at 4 PM MT because it is 3 PM Pacific. That works for the West Coast but forces Eastern teams to stay until 6 PM. Use the 10 AM to 3 PM MT window and you avoid both.
Best overlap hours with Eastern, Central, and Pacific
Eastern Time runs 2 hours ahead of MT year-round. A 9 AM Eastern call is 7 AM MT. Do that if you need to talk to New York before lunch, but do not make it your daily standup. A 10 AM MT call is 12 PM Eastern, a natural midday slot for both coasts.
Central Time runs 1 hour ahead of MT. That makes Central the easiest zone to pair with Mountain. A 9 AM MT call is 10 AM Central. A 3 PM MT call is 4 PM Central. If most of your team is split between Denver and Chicago, you can use a wider window: 8 AM to 4 PM MT works without anyone going outside a standard 8-to-5 day.
Pacific Time runs 1 hour behind MT. A 10 AM MT call is 9 AM Pacific. A 3 PM MT call is 2 PM Pacific. The Pacific team gets the earliest start and the earliest finish. If you schedule at 4 PM MT, Pacific is at 3 PM. That is still fine, but push it to 5 PM MT and Pacific hits 4 PM, which starts to cut into late afternoon work for some.
| Time zone | 10 AM MT | 3 PM MT |
|---|---|---|
| Eastern | 12 PM | 5 PM |
| Central | 11 AM | 4 PM |
| Pacific | 9 AM | 2 PM |
Scheduling with India and Europe from MT
India Standard Time is 12.5 hours ahead of MST and 11.5 hours ahead of MDT. On 15 July 2026, when MT is on MDT, 10 AM MT is 9:30 PM IST. That is a late evening conversation for India, but it is the best option if you need real-time discussion. A 7 AM MT call is 6:30 PM IST, more comfortable for the Indian side but painful for the MT side. Pick the one that hurts the smaller team.
Europe is easier. London is 7 hours ahead of MT in both winter and summer. A 10 AM MT call is 5 PM London. Paris is 8 hours ahead. A 10 AM MT call is 6 PM Paris. That is late afternoon for Europe. If you need morning Europe time, schedule at 3 AM MT. That is 10 AM London. Do not do that unless the conversation is critical and the MT team is small.
The common error with India: someone on the East Coast schedules a call at 2 PM Eastern without converting to IST first. 2 PM Eastern is 12 PM MT, which is 11:30 PM IST on MDT or 12:30 AM IST on MST. That is midnight for India. Always convert to the furthest time zone first.
Does Arizona stay on Mountain Time in summer?
Arizona does not observe daylight saving time. The state stays on Mountain Standard Time (MST, UTC-7) year-round. From March to November, when the rest of the Mountain Time zone moves to MDT (UTC-6), Arizona matches Pacific Daylight Time (PDT). Phoenix and Los Angeles show the same clock reading, but Phoenix is on MST and Los Angeles is on PDT. They are not the same time zone.
This creates the most common scheduling error in the Mountain zone. An East Coast manager looks at a calendar in July, sees "Mountain Time" for a colleague in Phoenix, and schedules a 2 PM MT call. 2 PM MDT is 2 PM Phoenix time only in winter. In July, 2 PM MDT is 1 PM Phoenix. The Phoenix person shows up an hour late.
The fix: always specify "Arizona time" or "MST" when scheduling with anyone in Phoenix, Tucson, Mesa, or any location in the state that does not observe DST. The Navajo Nation within the state does observe DST, so if you work with someone in Window Rock, you need to check. For everyone else, the rule is simple: Arizona matches Pacific in summer, Mountain in winter.
Tools and tips for distributed team calendars
Put your team's time zones in the event title. "Standup 10 AM MT / 12 PM ET / 9 AM PT" takes three seconds to type and saves ten minutes of confusion. Do not rely on the calendar tool to convert correctly. Google Calendar and Outlook both handle time zones well, but only if the event creator set the correct zone. If someone in Denver creates an event at 10 AM and their calendar is set to Denver time, the conversion works. If they set it to "Mountain Time" without specifying MST or MDT, the conversion may fail for colleagues in the state that stays on standard time.
Use a shared world clock. Pick a tool that shows four or five time zones at once. Many free options show UTC, Eastern, Mountain, Pacific, and IST in one row. Put it on a monitor that everyone on the team can see. It reduces the mental math and the "what time is it for you" Slack messages.
The one rule that stops 90% of errors: when you write a call time, write the UTC offset. "10:00 AM MDT (UTC-6)" or "10:00 AM MST (UTC-7)". If you do not know whether you are on MST or MDT, check. On 15 January 2026, Denver is on MST (UTC-7). On 15 July 2026, Denver is on MDT (UTC-6). The change happens on the second Sunday of March and the first Sunday of November.
Common scheduling errors and how to avoid them
Error 1: Assuming Arizona follows Mountain DST. Already covered. The fix is to treat that state as Pacific in summer and Mountain in winter, and always label it "Arizona time."
Error 2: Using "Mountain Standard Time" to mean "Mountain Time." MST is UTC-7. MDT is UTC-6. If you say "call at 2 PM MST" in July, you mean 2 PM UTC-7, which is 3 PM MDT. Most people who say "MST" in summer mean MDT. The fix: say "Mountain Time" or write the offset. Never write "MST" in a date range that includes March to November unless you mean UTC-7.
Error 3: Forgetting the 30-minute India offset. IST is UTC+5:30. That 30 minutes means a 10 AM MT call in winter is 10:30 PM IST, not 10 PM. In summer it is 9:30 PM IST. People round to the hour and miss by 30 minutes. The fix: use a converter that handles half-hour offsets.
Error 4: Scheduling recurring calls without checking DST changes. A weekly 10 AM MT call that works in January becomes 9 AM MT in March when clocks spring forward, if the call was created in a zone that does not change. The fix: create recurring calls from the MT zone, and check the March and November dates each year.
Error 5: Assuming everyone knows their own UTC offset. They do not. Ask. Then write it down.