Washington State Runs on Pacific Time, Basically
Washington State is in the Pacific Time Zone. That's the short answer. The longer answer involves daylight saving time, a few weird historical footnotes, and the fact that if you're scheduling anything with California or Oregon, you're already in the clear. If you're scheduling with anyone in Idaho or Nevada, read on. Pacific Standard Time (PST) is UTC-8. Pacific Daylight Time (PDT) is UTC-7. Washington observes daylight saving time, so the state flips between those two offsets every year. The switch happens on the second Sunday in March and the first Sunday in November, same as most of the United States. I've lost count of the number of times I've seen someone write "Pacific Time" in a calendar invite without specifying PST or PDT, then wonder why a meeting in February gets scheduled an hour off. It happens constantly. Just write the offset. UTC-8 or UTC-7. Five seconds of effort prevents three follow-up emails.
How Pacific Time Actually Works In Practice
The Pacific Time Zone covers the western third of the continental US. Washington, Oregon, California, most of Idaho, and parts of Nevada all sit in it. That means when it's 9 AM in Seattle, it's also 9 AM in Los Angeles and 9 AM in Portland. It's 6 AM in New York. It's 4 PM the same day in London during standard time. The counter-intuitive part that people miss: Pacific Time is not one uniform experience year-round. The six months of daylight saving time shift the entire state by an hour relative to the rest of the world, but not relative to its neighbors. Washington and California stay synchronized. Washington and Arizona, which doesn't observe DST, drift apart by an hour for most of the year. That matters if you're running operations across state lines.
The Edge Case That Bit Me
Back in 2019 I was coordinating a deployment window between a team in Seattle and another in Phoenix. Easy enough, right. Both on the West Coast. Wrong. It was mid-April, so Washington was on PDT (UTC-7) and Phoenix was on MST (UTC-7 year-round, no DST). They matched for about four months. Then in November, Washington flipped back to PST (UTC-8) while Phoenix stayed at UTC-7. Suddenly Phoenix was an hour ahead of Seattle and nobody had flagged it in the runbook. The fix was straightforward: I stopped using city names in scheduling and started using UTC offsets everywhere. "Deploy at 02:00 UTC" instead of "deploy at 6 PM Seattle time." Three years later I haven't had a single misaligned call since. It took about ten minutes to update the templates.
Get the Full Details
Common Mistakes People Make
The biggest one is assuming the whole state is uniform. It is, for time zone purposes, but the cultural and business rhythm isn't. Eastern Washington cities like Spokane operate on the same clock as Seattle, but their business hours skew slightly earlier because they're closer to Mountain Time culture. Not by much. Maybe fifteen minutes of de facto shift if you're sensitive to it. Most people aren't. The second mistake is ignoring the half-hour overlap periods during DST transitions. When clocks fall back in November, there's a one-hour window where both PST and the old PDT are technically valid. Scheduling systems handle it poorly. I've seen calendar invites land twice, disappear entirely, or show up with the wrong label. The workaround is to avoid scheduling anything between 1:00 AM and 2:00 AM on the day clocks fall back. Just don't do it. Pick a different window.
What This Means For Scheduling And Operations
If you're running a business that touches Washington State, here's what actually matters: During standard time (roughly early November to mid-March), Pacific Time is UTC-8. Your overlap with European business hours is narrow—maybe two to three hours in the morning if they're in Western Europe. If your team is in Germany or the UK, you're looking at early morning on your end and late afternoon on theirs. It's doable. It's not comfortable. During daylight saving time (mid-March to early November), Pacific Time shifts to UTC-7. The European overlap improves by an hour. Your 9 AM becomes 4 PM in London. That's the sweet spot if you need cross-Atlantic coordination.
For domestic coordination, you're golden with California and Oregon. Idaho is mostly fine but watch the panhandle—it's in the Pacific Time Zone but culturally and logistically tied to the rest of the state, so it follows Pacific Time without question. Southern Nevada is the actual problem area. Clark County (Las Vegas) is in the Pacific Time Zone, but if you're dealing with anyone in the rest of Nevada, you're now in Mountain Time. Don't assume.
The Technical Side
If you're building software that handles Washington timestamps, use the IANA time zone database. The identifier is America/Los_Angeles. Do not use "PST" or "PDT" as your zone identifier. Those are ambiguous and don't encode the DST rules. America/Los_Angeles does. It updates automatically when the US changes its DST schedule, which has happened multiple times in the last twenty years. Storing everything in UTC internally and converting to America/Los_Angeles only at display time is the standard approach. It adds maybe thirty minutes of development overhead up front and saves you from debugging timezone bugs that will absolutely find you later. I learned that the hard way. We had a billing system that ran on literal "PST" strings and it misbilled customers twice during transition weeks. Fixed it in a weekend. Won't happen again.
Bottom Line
Washington State is in the Pacific Time Zone. PST is UTC-8. PDT is UTC-7. The state observes daylight saving time. Use America/Los_Angeles in your code. Write UTC offsets in your meetings. Avoid scheduling during the fall-back transition hour. That's basically it. Anything more complicated than that is usually someone making it more complicated than it needs to be.
