PDT to MST Converter — Pacific Daylight to Mountain Standard Time (All Three Answers, Side by Side)

What this PDT to MST converter does — and why there isn’t one answer

Search for “PDT to MST converter” and almost every tool gives you a single number. That number is usually right for one interpretation and wrong for the other two. The reason is that “MST” is genuinely ambiguous, and the Pacific side changes its label twice a year as well. Here is the whole situation in one table:

PDT and MST are both UTC−7. That is the literal answer: 0 hours. But the two abbreviations are almost never observed at the same moment by the same place, because PDT is a summer label and MST is a winter label. When someone asks “what time is 9 AM PDT in MST?”, they usually mean one of two very different things:

• “I have a California time and I need the Colorado clock.” Denver observes MDT (UTC−6) in summer, so the answer is 10:00 AM MDT — 1 hour ahead. Denver observes MST (UTC−7) in winter, so the answer is 10:00 AM MST — still 1 hour ahead. Either way, always 1 hour ahead.
• “I have a California time and I need the Arizona clock.” Phoenix stays on MST (UTC−7) all year and never observes daylight saving. In summer, California and Arizona are on the same clock, so the answer is 9:00 AM MST — 0 hours apart. In winter, California is on PST (UTC−8) while Arizona is on MST (UTC−7), so the answer is 10:00 AM MST — 1 hour ahead. Date-dependent.

This tool shows all three answers — literal, Denver and Phoenix — in the triple-answer panel. You can pick which one you mean in the target dropdown, and the primary result updates while the other two stay visible for context. The insight panel explains in plain English which case applies to your selection, and the Three-way compare tab shows the same instant across all three zones with an offset ruler and a difference matrix.

📌 The one-sentence rule. If you mean Denver, the answer is always 1 hour ahead. If you mean Phoenix, the answer is 0 hours in summer and 1 hour in winter — and the flip happens exactly when California changes its clocks, not when Arizona does, because Arizona never changes.

Why search results disagree — and which answer is right for you

If you have already opened two or three converters, you have probably seen contradictory claims. One tool says “PDT and MST have the same time.” Another says “MST is 1 hour ahead of PDT.” A third says “PDT is 1 hour behind MDT.” None of them is lying — they are answering different questions without saying so. Here is what each claim actually means:

The reason this matters is practical: if you copy a summer screenshot of a converter into a December meeting invite, you will be an hour late. If you use a literal 0-hour answer for a Denver call, you will miss the first hour. The three-answer panel exists so you can see which interpretation applies to your date before you commit.

⚠ Watch out for free-file-converter style mistakes. At least one online converter has been observed confusing “MST” with “Macau Standard Time” (UTC+8). The abbreviation collision is real. If a result looks like a 15-hour shift instead of a 0–1-hour shift, you are almost certainly looking at the wrong “MST”.

Arizona is the key to the whole puzzle

Most of Arizona does not observe daylight saving time. It stays on Mountain Standard Time (MST, UTC−7) all year. This is the single fact that makes the PDT-to-MST conversion date-dependent, and it is the fact most converters skip.

The commonly cited reason is heat. Arizona opted out of DST in 1967, one year after the Uniform Time Act of 1966. An extra hour of evening daylight would push peak summer temperatures later into the day and increase cooling costs in a state that is already extremely hot. People were also unhappy about waiting until 9 PM for the sun to set before starting outdoor activities.

The Navajo Nation and Hopi Reservation exception

Arizona is not a single time zone in practice. The Navajo Nation, which spans northeastern Arizona, northwestern New Mexico and southeastern Utah, does observe DST and moves to MDT (UTC−6) in summer. The Hopi Reservation, which is entirely surrounded by the Navajo Nation inside Arizona, does not observe DST and stays on MST. Because of the enclaves and exclaves, driving a particular route through the region can require changing your clock several times.

If you are scheduling with someone in Window Rock, Tuba City, Chinle or Kayenta, use the Denver interpretation (MDT in summer). If you are scheduling with someone in Kykotsmovi or another Hopi village, use the Phoenix interpretation (MST year-round). If you are unsure, ask which city they are in — that is faster than guessing.

The Sonora mirror in Mexico

Directly south of Arizona, the Mexican state of Sonora also does not observe DST and stays on MST (UTC−7) all year. Its economy and social ties are closely linked to Arizona, and it has kept the same no-DST pattern. Hermosillo, the Sonora capital, therefore matches Phoenix exactly. Meanwhile, Baja California (including Tijuana and Mexicali) follows the US DST schedule and switches to PDT (UTC−7) in summer just like California. So Tijuana versus Hermosillo behaves exactly like Los Angeles versus Phoenix: 0 hours in summer, 1 hour in winter. The second row of clocks in the converter shows both of these Mexican zones live.

Why the literal answer and the practical answer differ

The confusion is not really about time zones — it is about the difference between an offset and an abbreviation. An offset is a fixed number of minutes from UTC. An abbreviation is a label that a specific place uses for its offset during a specific season. Two abbreviations can share an offset without ever being active at the same time.

Here is what actually happens across a calendar year:

The Los Angeles-to-Denver gap is always 1 hour because both cities change on the same dates. The Los Angeles-to-Phoenix gap flips from 0 to 1 hour on California’s spring-forward date, and from 1 to 0 hour on California’s fall-back date. The literal “PDT vs MST” comparison — both UTC−7 — is only a real clock match in summer, when California is actually on PDT and Arizona is actually on MST.

📌 The formula. LA → Denver = +1 h always. LA → Phoenix = 0 h in DST, +1 h in standard time. Denver → Phoenix = +1 h in summer, 0 h in winter. The three-way compare tab shows all three at once.

Common PDT to Mountain conversions at a glance

The table below covers the times people search for most. The literal column is fixed offset math. The Denver column is the practical California-to-Colorado answer for a summer date. The Phoenix column is the practical California-to-Arizona answer for a summer date.

💡 Which column should I use? If you are scheduling with someone in Denver, Colorado Springs, Salt Lake City, Albuquerque, Calgary or Edmonton, use the Denver column. If you are scheduling with someone in Phoenix, Tucson, most of Arizona or Hermosillo, use the Phoenix column. If you are doing literal UTC math or working with an API that specifies −07:00, use the literal column.

Your local time zone

The tool auto-detects your browser’s time zone via Intl.DateTimeFormat().resolvedOptions().timeZone. That returns the IANA name — for example America/Los_Angeles, Europe/London or Asia/Tokyo. The name appears in the green badge at the top of the converter and a live local clock runs alongside the Los Angeles, Denver, Phoenix, Tijuana and Hermosillo clocks.

If your local zone isn’t one of the built-in zones, a fresh “My local time” option is added to both dropdowns. Selecting it as the source converts from wherever you are to whichever Mountain interpretation you pick; the Use as source button switches the current source to your local zone in one click. That makes the tool equally usable as an “any time zone to Mountain Time” converter or a “PDT to my time” converter.

💡 Privacy note. The detection happens entirely in your browser. The name is not transmitted anywhere — it only influences which options show up in the dropdowns on your own device.

When PDT is observed — the US DST schedule and 2026 dates

PDT only exists during daylight saving time. The US federal schedule, unchanged since 2007, runs from the second Sunday in March to the first Sunday in November. In 2026 those dates are Sunday 8 March and Sunday 1 November.

Outside that window, California is on PST (UTC−8), not PDT. If you enter a winter date with Los Angeles selected as the source, the tool labels the result as PST — because that is the abbreviation that actually applies on that date. There is no such thing as “PDT in December.”

If you genuinely need a UTC−7 conversion regardless of the calendar, select PDT fixed from the source dropdown. That option is always UTC−7 and never changes with the date.

⚠ Spring-forward and fall-back edge cases. On 8 March 2026 the wall-clock times between 2:00 AM and 2:59 AM do not exist in Los Angeles or Denver. On 1 November 2026 the 1:00 AM–1:59 AM window happens twice. Phoenix, Hermosillo and the Hopi Reservation never have either problem because they never change. The tool flags both cases so you don’t schedule a meeting for a time that never happened (or happened twice).

How to convert PDT to MST by hand

Because the answer depends on which Mountain zone you mean, the hand-conversion has four branches.

Branch 1 — literal offset math (PDT as UTC−7 → MST as UTC−7)

This is what you get when you pick PDT fixed and MST fixed in the dropdowns. It is mathematically correct and it is what most textbooks show.

Branch 2 — practical Los Angeles → Denver during summer (March–November)

This is the answer most people want when they say “MST” meaning Colorado. Note the target abbreviation is MDT, not MST, because Denver is not on MST in summer.

Branch 3 — practical Los Angeles → Denver during winter (November–March)

Same one-hour shift, different abbreviations. The Los Angeles-to-Denver gap never changes because both cities follow the same DST schedule.

Branch 4 — practical Los Angeles → Phoenix (the date-dependent case)

This is the branch that catches people out. If you use a summer screenshot of a converter to plan a December meeting with Phoenix, you will be an hour late. The tool lets you switch dates and shows the correct relationship for whichever date you pick.

Finding a meeting slot that works for both zones

Because the gap is only 0–1 hour, the working-hours overlap is almost complete. If both sides work a standard 9 AM–5 PM day, the shared window runs from 9 AM to 4 PM Pacific when calling Denver (because Denver is 1 hour ahead), or the full 9 AM to 5 PM when calling Phoenix in summer (because they are on the same clock).

The golden window — the mid-day block that is comfortable for both offices — is 10 AM–3 PM Pacific. In summer that corresponds to 11 AM–4 PM MDT in Denver or 10 AM–3 PM MST in Phoenix. In winter it corresponds to 11 AM–4 PM MST in Denver or 11 AM–4 PM MST in Phoenix. The Golden window tab shades exactly this block across the next seven days so you can see it rather than calculate it.

The Meeting planner tab turns the same data into day cards showing both the Denver and Phoenix overlap hours for each of the next 7 days, with a “Best” badge on the day with the longest overlap and a suggested mid-day slot.

Real-world scenarios where this conversion matters

Scenario 1 — the California-to-Colorado standup

A team with engineers in San Francisco and product managers in Denver schedules a daily standup at 9:00 AM Pacific. Because Denver observes DST on the same schedule as California, the standup is always 10:00 AM in Denver — 10 AM MDT in summer, 10 AM MST in winter. The clock time in Denver never jumps by two hours; only the abbreviation changes. If you write the invite as “9 AM PT” and let the calendar handle the conversion, you will never have a problem.

Scenario 2 — the California-to-Arizona quarterly review

A consulting firm in Los Angeles has a client in Phoenix. In summer (March–November) a 2 PM meeting in LA is 2 PM in Phoenix — the same clock. But the December quarterly review booked from the summer template will land at 3 PM Phoenix time, not 2 PM, because California has fallen back to PST while Arizona has not moved. This is the single most common scheduling error between West Coast and Arizona teams. The tool’s date-dependent Phoenix answer exists specifically to catch it.

Scenario 3 — TV broadcasting “8/7 Mountain”

US prime-time TV is usually announced as “8/7 Central” on the East Coast and “8 PM Pacific” on the West Coast. In the Mountain zone, the same broadcast hits Denver at 9 PM MDT (because Denver is 1 hour ahead of Los Angeles in summer) and Phoenix at 8 PM MST (because Phoenix is on the same clock as Los Angeles in summer). So a single national broadcast has two different Mountain-zone local times depending on which Mountain city you are in. This is genuinely confusing and is the reason many streaming services list “Mountain” as a single zone even though Arizona and Colorado are not the same.

Scenario 4 — the calendar API problem

A developer stores a scheduled event as “2026-07-15T12:00:00-07:00” and calls it a “PDT” event. The offset −07:00 is correct for PDT. But a downstream consumer might read −07:00 as “MST” (Arizona) and display it as 12 PM Arizona time — which happens to be correct in summer, because Arizona is also UTC−7. If the event were in December, the same −07:00 would be MST (Arizona) but the “PDT” label would be wrong. The cleanest fix is to store an explicit IANA zone (America/Los_Angeles or America/Phoenix) rather than an abbreviation, so the DST behaviour is unambiguous.

Scenario 5 — the Tijuana–Hermosillo border call

A manufacturing team in Tijuana (Baja California) coordinates with a supplier in Hermosillo (Sonora). Because Baja California follows the US DST schedule and Sonora does not, the two cities are on the same clock from March to November and 1 hour apart from November to March. This is the exact Mexican mirror of the Los Angeles–Phoenix relationship, and the second row of live clocks in the converter shows both cities so you can verify the current gap at a glance.

Common mistakes when converting PDT to MST

• Assuming PDT is always 1 hour behind MST. It isn’t — both are UTC−7, so the literal difference is 0. The 1-hour difference people experience is PDT vs MDT (Denver in summer) or PST vs MST (winter California to winter Arizona).
• Assuming Denver is on MST in summer. Denver is on MDT (UTC−6) from March to November. Saying “Denver MST” in July is technically wrong. The clock is still 10 AM when it is 9 AM in LA, but the label is MDT.
• Assuming Phoenix is on MDT in summer. Phoenix never changes. It is always MST (UTC−7).
• Using a summer answer for a winter meeting. The California-to-Arizona gap flips on California’s DST dates. If you build a meeting template in July and run it in December, the Phoenix clock will be an hour later than you expect.
• Forgetting the Navajo Nation. The Navajo Nation observes DST even though it is inside Arizona. If your counterpart is in Window Rock, Tuba City or Kayenta, use the Denver interpretation.
• Forgetting the Hopi Reservation. The Hopi Reservation is inside Arizona and inside the Navajo Nation, but it does not observe DST. If your counterpart is in Kykotsmovi or another Hopi village, use the Phoenix interpretation.
• Forgetting Sonora. Sonora stays on MST (UTC−7) all year, unlike Baja California which follows the US schedule. A Tijuana-to-Hermosillo call flips on California’s DST dates, not on Mexico’s old DST dates.
• Forgetting the date rollover. 11:30 PM PDT on Monday is 12:30 AM MDT on Tuesday when converting to Denver. A converter that only shifts the clock and not the calendar produces the wrong date.
• Storing times as abbreviations. If you store “3 PM MST” in a database, consumers will interpret it differently depending on whether they think MST means Denver in winter or Arizona year-round. Store the UTC instant or the IANA zone name.
• Treating “MST” as China Standard Time. China Standard Time is UTC+8 — fifteen hours ahead of PDT. The abbreviation collision causes real problems in international scheduling, and at least one online converter has been observed making this exact mistake.

Who actually needs this conversion

• Remote teams spanning California, Colorado and Arizona. Any recurring meeting needs the correct 1-hour shift for Denver and the date-dependent 0-or-1-hour shift for Phoenix.
• Broadcast and media. A national show airs at 8 PM Pacific, 9 PM Mountain (Denver) and 8 PM Mountain (Phoenix) in summer — the two Mountain cities are not the same local clock.
• Sports scheduling. A game listed as 7:00 PM PT is 8:00 PM MT in Denver and 7:00 PM MST in Phoenix during summer.
• Event organisers announcing a start time. A webinar at 10 AM PT needs a separate line for Denver and Phoenix if you want both to be accurate.
• Customer support teams. SLA windows published in Pacific Time need a Mountain equivalent — and the Mountain equivalent differs for Arizona vs Colorado.
• Legal and compliance teams. Deadlines specified in a specific time zone need conversion for the counterparty, and the counterparty’s zone may be Arizona rather than Colorado.
• Developers writing calendar invites and cron jobs. A recurring meeting scheduled at 9 AM PDT in summer will be 9 AM PST in winter — the tool makes the DST-aware date visible.
• Cross-border manufacturing and logistics. Tijuana (Pacific, US DST) versus Hermosillo (MST, no DST) is the Mexican mirror of LA versus Phoenix, and it matters for shift planning.
• Freelancers and contractors worldwide. Convert your own local time to a client’s Mountain Time without needing to know either offset off by heart.
• Anyone confused by the 0-hour vs 1-hour discrepancy. The triple-answer panel, insight panel and three-way compare tab exist specifically to clear up this confusion.

Limitations

• The tool uses the browser’s built-in IANA time-zone database via Intl.DateTimeFormat. If a government changes its DST law and your browser has not been updated, the result may lag.
• The selectable city list covers the most common North American zones. For other zones, select My local time (if you are in that zone) or verify the offset separately and use the fixed-offset options.
• Ambiguous fall-back times (the 1:00–1:59 AM window on 1 November 2026) are resolved by taking the first occurrence. The tool warns you when this happens.
• The meeting planner and golden-window heatmap assume a standard 9 AM–5 PM working day in both zones. If your team works different hours, the shaded windows will not match your reality.
• The converter does not schedule recurring meetings or generate calendar files beyond a single-event .ics.
• Local time-zone detection relies on the browser reporting correctly. Some privacy-hardened browsers (e.g. Tor Browser) report UTC instead of the true local zone.

Frequently asked questions

Related time tools on AIToolsPros