Working With Pacific Time: What Actually Happens
Pacific Time isn't one timezone. It's two shifted offsets that switch based on a calendar rule most people don't fully understand, and that gap between understanding and being right is where scheduling failures happen. PDT is Pacific Daylight Time, UTC7. PST is Pacific Standard Time, UTC8. The difference matters when you're booking a call between Los Angeles and London, or when your deployment pipeline runs at midnight and you've misread which offset applies. PDT covers the western portion of North America during the daylight saving window. California, most of Oregon and Washington, Nevada (), parts of Idaho, and Baja California in Mexico observe it. Canada does too — British Columbia, the Yukon, and parts of Saskatchewan's border territories. The region spans roughly 3,000 miles north to south, and yes, everyone in that strip shifts together even though sunrise varies by over an hour between Seattle and Tijuana. Daylight saving in the US begins on the second Sunday in March at 2:00 AM local time, when clocks jump forward to 3:00 AM. It ends on the first Sunday in November at 2:00 AM, when clocks fall back to 1:00 AM. That means for about eight months of the year, Pacific Time runs UTC7. For the remaining four months, it runs UTC8. The IANA timezone identifier for the region is America/Los_Angeles, and if you're writing code that handles scheduling, use that identifier rather than hardcoding an offset. Hardcoded offsets will break you on transition days every single time.
I learned this the hard way in 2022 when a colleague in Vancouver set up an automated report that ran daily at 6:00 AM Pacific and emailed it to stakeholders in New York. The script stored the send time as a raw offset of UTC8 instead of using the timezone database. On November 6th, when clocks fell back, the report arrived at 7:00 AM Eastern instead of 6:00 AM because the offset was still locked to PST while the region was technically still in PDT until 2:00 AM that morning. It took me twenty minutes to trace the issue, but the fix was straightforward: switch from offset-based storage to named timezone storage using pytz.timezone('America/Los_Angeles') in Python or DateTimeZone.forID('America/Los_Angeles') in Java. Once that change went in, transition-day errors dropped to zero.
Common Pitfalls That Cost People Time
The biggest mistake I see is assuming PDT and PST are interchangeable labels. They're not. If you schedule a meeting for "10:00 AM PDT" in October, that's a different wall-clock moment than "10:00 AM PST." The UTC equivalent shifts by exactly one hour. People who treat them as the same end up either showing up an hour early or an hour late, and they blame the other person for being wrong. Another trap: assuming the entire Pacific region follows the same rule. Mexico changed its daylight saving policy in 2022. Most of Baja California still observes DST and therefore switches between PST and PDT like the US does, but the rest of Mexico eliminated seasonal time changes for most of the country. If you're coordinating with a team split between Tijuana and Mexico City, you can't assume they share the same offset even when they're in the same country. Tijuana is UTC7 during PDT and UTC8 during PST. Mexico City sits at UTC6 year-round in most of the current policy framework. That's a two-hour gap that exists regardless of which Pacific clock you're looking at.
Get the Full Details
What This Means for Practical Work
If you're building a system that handles Pacific Time, store timestamps in UTC internally and convert to America/Los_Angeles only at the presentation layer. This eliminates the transition-day edge cases entirely. If you're manually scheduling across Pacific and Eastern time zones during daylight saving months, remember that the gap is three hours, not four. During standard time, the gap flips to four hours. I keep a simple reference table on my desk because my brain doesn't reliably remember which gap applies at any given month. The IANA database handles historical transitions automatically, including the brief period in 1945 when the US observed constant daylight saving year-round under War Time, and the 1974–1975 experiment with year-round DST that Nixon authorized after the oil crisis. Most modern libraries absorb these correctly. Older systems or custom implementations that try to approximate DST rules with simple formulas will produce wrong results for any date before 2007, when the current US DST schedule was standardized by the Energy Policy Act.
When Pacific Time Doesn't Help You
PDT as a concept only applies to the western third of North America. It doesn't cover Hawaii, which stays on HST (UTC10) year-round and doesn't observe daylight saving at all. It doesn't cover Arizona either, which largely ignores DST and stays on MST (UTC7) all year. If you're booking a call with someone in Phoenix and someone in Los Angeles during summer, they're actually on the same offset — UTC7 — despite one being in "standard" time and the other in "daylight" time. That similarity is misleading because it vanishes the moment DST ends and Phoenix stays put while LA drops an hour. For anything beyond casual scheduling, the reliable path is using the timezone name, not the offset abbreviation. PDT and PST are ambiguous in isolation. America/Los_Angeles is not. That's the difference between a calendar invite that works and one that causes confusion every spring and fall.
