Mountain Time: The Actual Rules When You're Not Just Guessing
The Mountain Time Zone sits at UTC-7 during standard time and UTC-6 during daylight saving. That's the textbook answer. But if you've ever tried to coordinate a call between someone in Phoenix and someone in Denver, you already know the textbook is wrong in about twenty percent of cases. Mountain Time covers most of Colorado, Utah, Arizona, New Mexico, and parts of Montana, Wyoming, Idaho, and Nevada. It also dips into two Canadian provinces and several Mexican states. The zone itself is straightforward. The exceptions are what break your schedule. I spent three years managing shift rotations for a logistics platform that ran dispatch calls across the Mountain and Pacific zones. We had a bug where the scheduling engine assumed Arizona followed DST. It didn't. I watched a dispatcher miss a handoff window by an hour because the system thought Phoenix was on MDT when it was actually on MST the entire time. The fix was simple: strip Arizona from the DST offset map entirely and hardcode it to UTC-7 year-round. But catching it took about six weeks of error reports piling up from the Phoenix field office.
Where People Get It Wrong
The biggest issue is the DST split within the zone itself. Most of Mountain Time observes daylight saving. Arizona does not. Most of Navajo Nation in northeastern Arizona does. That means you can drive three miles across a state line and suddenly be in a different effective time offset. Idaho is another mess. The northern half of Idaho sits in Mountain Time but follows DST. The panhandle does not — it stays on Pacific Time year-round. When Idaho reorganized its time zones in 1972, they tried to draw clean lines along county borders. They didn't quite work out that way in practice. Here's the counter-intuitive part that trips people up: when DST is active, Mountain Daylight Time (MDT, UTC-6) and Pacific Daylight Time (PDT, UTC-6) are on the same clock time. But when DST ends, Mountain Standard Time (MST, UTC-7) is one hour ahead of Pacific Standard Time (PST, UTC-8). So the gap between these zones flips depending on the time of year. If you schedule something based on a phone call in July and forget the clocks change in November, you will show up an hour early or late and nobody will remember why.
TheMexico Factor
Sonora, Chihuahua, and a few other Mexican states near the Arizona border are in Mountain Time but do not observe DST either. This creates a situation where Tucson and Ciudad Juárez are on the same offset for most of the year, but for roughly seven weeks in summer when the US is on MDT and Mexico stays on MCT, Tucson is an hour ahead of Juárez. Cross-border supply chain coordination at that window requires explicit attention to which side is shifting. I once had a freight coordinator lose a container handoff because the receiving dock in Nogales assumed the truck would arrive on MDT. It was October. The US had fallen back. The Mexican side had not. The appointment window was off by sixty minutes and the dock crew had already cleared the bay for a different load. We now flag any appointment falling between early November and mid-March as requiring manual confirmation of the local offset on both sides of the border. It adds maybe four minutes to the scheduling process but prevents the kind of waste that costs hundreds per incident.
Get the Full Details
How to Handle This Without Losing Your Mind
Don't store or display times in local strings unless you absolutely have to. Use UTC internally. Convert to local only at the edges of your system. This is the single most effective rule and the one most teams skip because it feels like extra work during development. If you're building something that handles scheduling, use the IANA time zone database, not fixed UTC offsets. Arizona is America/Phoenix, not "Mountain Time minus DST." The database has the correct historical transitions and the weird edge cases like Navajo Nation already baked in. Hardcoding offsets gets you wrong answers around DST boundaries and whenever Congress or a state legislature changes the rules — which happens more often than people admit. For manual calculations, the quickest reliable method is to remember that Mountain Standard Time is UTC-7 and Mountain Daylight Time is UTC-6. DST in the US runs from the second Sunday in March to the first Sunday in November. Arizona and most of Saskatchewan stay on UTC-7 all year. If you're outside those areas and the date falls between those Sunday boundaries, subtract 6. Otherwise subtract 7.
When This Approach Fails Completely
The IANA database doesn't solve every problem. If you're coordinating across the US-Mexico border during a year when Mexico changes its DST policy mid-season, your database might still be off until the next update cycle. Mexico has shifted its approach to DST at least three times since 2020, sometimes reverting to previous rules retroactively in ways that catch automated systems unprepared. Also, the Navajo Nation exception is small enough that most general-purpose time zone tools don't flag it clearly. If your system treats all of Arizona uniformly, you'll be wrong inside the Navajo reservation. I learned that one the hard way when a community event we were helping coordinate got confused about start time because our booking tool applied standard Arizona logic to a venue that sits partly inside the reservation boundaries.
Quick Reference For Common Scenarios
Denver in January: UTC-7. Denver in July: UTC-6. Phoenix all year: UTC-7. Salt Lake City in January: UTC-7. Salt Lake City in July: UTC-6. Albuquerque all year during DST: UTC-6, outside DST: UTC-7. Durango in November after the fall back: UTC-7. El Paso in December: UTC-7. Most of Montana in August: UTC-6. The panhandle of Idaho in March before DST starts: UTC-7, which is technically Mountain Standard but functionally indistinguishable from Pacific at that point since the region has been transitioning. If you need to verify a specific location right now, check whether it's inside Arizona (except Navajo Nation) or the Navajo Nation itself. That split alone accounts for roughly ninety percent of the scheduling errors I see come through support tickets. Everything else is just making sure you know which Sunday the clocks change and whether your partner across the border is following the same calendar.
