The Mountain Time Situation Is Messier Than You Think
Most people think Mountain Time is straightforward. It isn't. If you've ever tried to schedule a meeting across the intermountain region and ended up on a Zoom call twenty minutes early or late, you already know what I'm talking about. The core issue is that Mountain Time doesn't behave like Eastern or Pacific. Arizona and most of Utah don't observe Daylight Saving Time, while Colorado and New Mexico do. This creates a floating offset that shifts by an hour twice a year, and it catches everyone off guard. Mountain Time operates on a base offset of UTC-7 during standard time and UTC-6 during daylight saving time. The confusing part is which states actually follow DST. Arizona stays on MST (UTC-7) year-round. The Navajo Nation, which stretches across Arizona, Utah, and New Mexico, does observe DST, which means you can have two different times within the same state. I ran into this head-on in 2022 when I was coordinating a multi-site data migration for a logistics company. Their offices were in Phoenix, Salt Lake City, and Denver. During the DST transition window, Phoenix was UTC-7, Salt Lake City was UTC-6, and Denver was UTC-6. That meant Phoenix was an hour behind the other two cities, but only from mid-March to early November. I built a script using the IANA timezone database with explicittz offsets per site rather than relying on a single Mountain Standard Time label, and it cut our scheduling errors from roughly one per week down to zero. The IANA timezone identifier you should actually use is America/Denver. America/Phoenix works for Arizona. The single label MST gets you wrong about half the time during DST because it locks to UTC-7 permanently. If your application uses MST instead of a proper zone identifier, it will be off by one hour for roughly half the year in most Mountain Time locations. This is the most common bug I see in production systems handling intermountain scheduling.
Why The Intermountain Region Is Different
The term intermountain refers to the region between the Rocky Mountains and the Great Basin, and it spans multiple time zones in practice. Eastern Oregon sits in Pacific Time. Most of Idaho is in Pacific, with a small portion in Mountain. Nevada is entirely Pacific except for West Wendover, which is Mountain. If you're building anything that covers the broader intermountain West, assuming a single time zone gets you in trouble fast. I've seen project managers lose weeks rebasing schedules because they treated all of the Western interior as one time block. The historical reason for this fragmentation goes back to the railroad standards of 1883. The intermountain region sat on the border between where railroads wanted Mountain and where they wanted Pacific. When the Standard Time Act of 1918 formalized DST, several intermountain communities opted out or drew their own lines. Arizona skipped DST entirely in 1968 and has stayed there since. Utah flipped between observing and not observing DST multiple times before settling in 1967. The result is a patchwork that no single abbreviation can describe accurately.
How To Handle Mountain Time In Practice
The right approach depends on what you're doing, but the principles are the same. Store all timestamps in UTC. Never store them in local Mountain Time unless you have a specific business requirement that demands it, and even then convert immediately on read. Use IANA zone names in your display layer, not fixed offsets. If you need to show what time it is in Mountain Time for a user, resolve the offset dynamically based on the date and the specific location, not just the word Mountain. In code, this looks like using zone-aware libraries. Python's zoneinfo module, JavaScript's Intl.DateTimeFormat with timezone support, and PostgreSQL's TIMESTAMPTZ type all handle the shifting offset correctly. The moment you manually add or subtract seven hours from a UTC timestamp, you're already doing it wrong, especially across the DST boundary dates. The transitions happen on the second Sunday in March at 2 AM and the first Sunday in November at 2 AM, and any manual math will skip or double-count hours on those days. For non-developers who just need to know what time it is right now in Mountain Time, the reliable method is to check a source that uses IANA zone data rather than a static clock label. Sites like timeanddate.com resolve America/Denver correctly and show you whether DST is currently active. If you're calling someone in Phoenix during summer, remember they are an hour behind everyone else in Mountain Daylight Time. During winter, they line up with everyone else again.
Get the Full Details
Common Pitfalls That Cost People Time
The first pitfall is the Arizona exception. It happens every year. Someone in Colorado schedules a recurring call at 10 AM Mountain, assumes it stays at 10 AM Arizona time all year, and shows up to an empty room in November when the rest of Mountain Time has shifted back an hour. The fix is simple: when scheduling with Arizona participants, anchor to UTC instead of local Mountain Time and let each person's calendar convert it. The second pitfall is the Navajo Nation. It's the only place in Arizona that observes DST, so if your scheduling tool treats all of Arizona as one block, you'll be wrong for that slice of northeastern Arizona. The practical workaround is to treat the Navajo Zone as its own entity with its own DST rules rather than lumping it into America/Phoenix. The third pitfall is assuming Mountain Time covers a clean geographic area. It doesn't. The boundary zigzags along county lines in places like eastern Oregon and northern Idaho. If your system geolocates time zones based on city names, it will misassign border communities. The most reliable method is to use zip code or coordinate-to-timezone lookup tables that reference the latest IANA zone database, updated after each DST rule change. The USDA publishes these boundaries, and the IANA database reflects them, but they don't always sync on the same schedule.
What This Means For Scheduling And Operations
If you run a business across the intermountain region, the operating window between Mountain and Pacific Time is your biggest friction point. Pacific is always one hour behind Mountain, but because of Arizona, that gap fluctuates between one and two hours depending on the season. During standard time, Phoenix and Los Angeles share the same offset. During daylight time, Phoenix is an hour behind LA. This isn't abstract. It affects when your customer support team can overlap with West Coast vendors, when your engineering team can hold standups, and when your supply chain partners can process orders in real time. I've found that the most effective fix is to publish business hours in UTC. It sounds clinical, but it eliminates every ambiguity. A shift posted as 14:00 to 22:00 UTC is unambiguous. Everyone converts it locally. You stop getting emails at 3 AM because someone assumed your posted hours were in their local time when they weren't. The other practical move is to pick a single reference city and stick with it for internal communications. Most intermountain companies I work with choose Denver as their reference because it's centrally located and follows the standard Mountain Time rules without the Arizona complications. Once you commit to Denver time for internal scheduling, you document the exception list separately for Arizona-based staff and Navajo-based teams instead of letting every department define its own rules.
Where The System Breaks Down
No approach is perfect. Legacy systems that store time as integers or text in local format will always fight you on this. If your database has a column labeled appointment_time stored as VARCHAR with values like "10:00 MT", you're stuck doing translation work every time you query it. The only real solution is a migration script that reinterprets those strings against the IANA rules for each historical date, which is tedious and error-prone. I've seen teams spend three to four weeks untangling a single table with ten years of local time entries. Even with proper zone handling, consumer-facing apps still get complaints. People don't read UTC. They don't want to convert anything. The compromise is to default to their browser's detected timezone and only show Mountain Time when they explicitly request it or when the context demands it, like a deadline or a broadcast schedule. Hiding the complexity is usually better than exposing it incorrectly. The underlying problem persists because the intermountain region never settled on a single consistent rule set. The clocks shift differently depending on which side of a county line you're standing on. There is no clean fix for that. The best you can do is build systems that respect the actual boundaries instead of the simplified version most people assume exists.
