If you have ever opened a calendar invite from a colleague in Los Angeles and seen it stamped PST in February but PDT in June — and possibly just PT when the sender did not want to think about it — you have already met the source of one of the most common scheduling errors in business software. The U.S. and Canadian Pacific coast does not have a single time zone. It has one zone with two names, and a third shorthand for when the speaker does not want to commit. This article explains exactly when each abbreviation applies, how the daylight saving schedule was set in U.S. federal law, why Arizona and a part of northern Mexico do their own thing, and how to convert Pacific Time to and from UTC, Mountain, Central, Eastern, CET, and Australian Eastern Time without making the classic one-hour mistake.
The rule in one sentence
Pacific Standard Time (PST) is UTC−8 and is in force from the first Sunday in November to the second Sunday in March. Pacific Daylight Time (PDT) is UTC−7 and is in force from the second Sunday in March to the first Sunday in November. PTmeans "Pacific Time, whichever one is in effect right now," and it is what most U.S. broadcasters and many publishers use to avoid the issue.
The IANA time zone database represents the whole region with the identifier America/Los_Angeles, which carries the full history of every transition the zone has ever had — including the 2007 change that lengthened daylight time by about a month. Modern operating systems and programming languages all read those rules from tzdata, which is why a meeting created in Outlook on a laptop in Vancouver shows the right local hour when opened in Tokyo.
What the abbreviations actually mean
The four-letter framework is consistent across the U.S. zones. The first letter is the region (Pacific, Mountain, Central, Eastern, Atlantic, Hawaiian). The second letter is either Standard or Daylight. The third letter is always Time. So:
- PST— Pacific Standard Time, UTC−8. The "winter" clock setting in the Pacific Time Zone.
- PDT— Pacific Daylight Time, UTC−7. The "summer" clock setting in the Pacific Time Zone.
- PT— Pacific Time, generic. Used in news broadcasts, sports schedules, and informal writing to avoid having to know which of the two is currently in effect. A line like "tonight at 8 p.m. PT" means whichever Pacific clock is ticking at broadcast time.
The same pattern produces EST/EDT/ET, CST/CDT/CT, and MST/MDT/MT. Hawaii uses HST (UTC−10) and does not observe daylight saving time. Alaska uses AKST and AKDT.
When does each one apply
The U.S. Department of Transportation, which has jurisdiction over time zones under the Uniform Time Act of 1966, sets the dates of daylight saving time transitions for the country. The current schedule was extended by the Energy Policy Act of 2005, which took effect in 2007 and added roughly four weeks to U.S. daylight saving time. Under the current rules:
- Spring forward: the second Sunday in March, at 2:00 a.m. local time, clocks jump from 2:00 to 3:00. PST ends; PDT begins.
- Fall back: the first Sunday in November, at 2:00 a.m. local time, clocks fall from 2:00 back to 1:00. PDT ends; PST begins.
This means PST is in force for roughly four months a year (mid-November through early-to-mid March), and PDT is in force for roughly eight months. That ratio surprises people who still mentally split the year in halves. Canada's federal government and the western provinces — British Columbia, Yukon (the parts that still observe it), and adjacent jurisdictions — match the U.S. schedule.
Arizona, Mexico, and the exceptions
Not every part of North America that touches the Pacific Time Zone observes the same DST rules. Three exceptions matter for scheduling.
- Arizona (most of the state).Arizona is in the Mountain Time Zone but does not observe daylight saving time. Phoenix stays on MST (UTC−7) year-round. That means in summer, when Pacific is on PDT (also UTC−7), Phoenix and Los Angeles share the same wall-clock time. In winter, Phoenix is one hour ahead of Los Angeles. The Navajo Nation, which lies in northeastern Arizona, does observe DST, so part of Arizona moves and part does not.
- Hawaii.Pacific in geography, but in its own zone (HST, UTC−10) and not on DST. Two hours behind Pacific in winter, three hours behind in summer.
- Baja California, Mexico. The Mexican state of Baja California (Tijuana, Mexicali, Ensenada) lies in the Pacific Time Zone and, by Mexican federal regulation, observes the same DST schedule as the United States. So Tijuana and San Diego are always on the same clock. The rest of Mexico, since 2022, no longer observes DST in most of the country, but the Baja California exception remains in place to keep cross-border commerce in sync.
A short history of US daylight saving time
The United States first experimented with daylight saving during World War I as an energy-conservation measure, then repealed the federal version after the war and let states and cities decide on their own. By the early 1960s the situation was chaotic — at one point, riding a bus from Steubenville, Ohio to Moundsville, West Virginia required passing through seven different time changes in thirty-five miles. The Uniform Time Act of 1966 ended that by setting a national framework: states could opt out of DST entirely, but if they observed it they had to do so on the same dates everyone else did.
The boundaries of those dates have shifted over the decades. From 1986 through 2006 DST ran from the first Sunday in April to the last Sunday in October. The Energy Policy Act of 2005moved the start earlier and the end later, producing the current second-Sunday-in-March to first-Sunday-in-November window starting in 2007. Several proposals in Congress since then have attempted to make daylight saving time permanent — eliminating the spring-forward and fall-back transitions — but as of this article's publication, none has become law.
How modern software handles this
For practical purposes, a calendar app, a database, or a scheduling system should never store "PST" or "PDT" as the time zone. Both are surface labels that depend on the date of the event. Store the IANA identifier — for the U.S. west coast, that is America/Los_Angeles — and let the runtime compute the offset. Vancouver uses America/Vancouver; Tijuana uses America/Tijuana; the Yukon, where most of the territory's government has stopped observing DST, uses America/Whitehorse (and some legacy systems still ship America/Dawson for the same reason).
Storing the IANA name solves three problems at once: it picks up future legislation automatically when tzdata is updated, it survives any past rule change without losing the meaning of historical timestamps, and it removes the ambiguity that PST/PDT introduce when an event is created across the spring-forward boundary.
Quick reference: Pacific Time across major hubs
The table below shows what 9:00 a.m. on a Tuesday in Los Angeles looks like in the cities most likely to be on the other end of a Pacific-coast video call, in both PST (winter) and PDT (summer) windows. The receiving city's offset shifts depending on its own DST status, which is why the column entries are not always consistent.
| City (zone) | 9:00 PST in Los Angeles (Northern Winter) | 9:00 PDT in Los Angeles (Northern Summer) |
|---|---|---|
| Los Angeles / San Francisco / Vancouver | Tue 09:00 (PST, UTC−8) | Tue 09:00 (PDT, UTC−7) |
| Phoenix (MST, no DST) | Tue 10:00 | Tue 09:00 |
| Denver / Calgary (MST/MDT) | Tue 10:00 (MST) | Tue 10:00 (MDT) |
| Chicago / Mexico City (CST/CDT) | Tue 11:00 (CST) | Tue 11:00 (CDT) |
| New York / Toronto (EST/EDT) | Tue 12:00 (EST) | Tue 12:00 (EDT) |
| UTC | Tue 17:00 | Tue 16:00 |
| London (GMT/BST) | Tue 17:00 (GMT) | Tue 17:00 (BST) |
| Paris / Berlin (CET/CEST) | Tue 18:00 (CET) | Tue 18:00 (CEST) |
| Tokyo (JST, no DST) | Wed 02:00 | Wed 01:00 |
| Sydney (AEDT/AEST, reverse seasons) | Wed 04:00 (AEDT, UTC+11) | Wed 02:00 (AEST, UTC+10) |
Worked examples
Example 1 — PST to UTC.A standup meeting at 9:00 a.m. on Tuesday, January 14 in Los Angeles. Pacific is on PST that morning, so the offset is UTC−8. Add 8 hours: the meeting is 17:00 UTC on Tuesday, January 14. Stored in a database, that becomes a single unambiguous instant.
Example 2 — PDT to CET.A demo at 11:00 a.m. on Tuesday, July 8 in San Francisco. Pacific is on PDT, UTC−7. Frankfurt is on CEST, UTC+2. Total shift: nine hours forward. The meeting is 20:00 in Frankfurt, which is 8:00 p.m. local — workable but late.
Example 3 — the Australia trap. A meeting set for 4:00 p.m. on Tuesday in Los Angeles to land at a reasonable morning hour for a partner in Sydney. In northern winter (PST in LA, AEDT in Sydney), 16:00 PST + 19 hours = 11:00 Wednesday AEDT. In northern summer (PDT in LA, AEST in Sydney), 16:00 PDT + 17 hours = 9:00 Wednesday AEST. Same meeting on the same wall clock in Los Angeles, but a two-hour swing on the Sydney side because both ends move and in opposite directions. This is the kind of mistake that costs a product launch its first kickoff.
Example 4 — the spring-forward gap. A nightly batch job scheduled to run at 2:30 a.m. local time in Los Angeles will never run on the second Sunday of March, because 2:00 a.m. skips directly to 3:00 a.m. and 2:30 simply does not exist that day. Conversely, on the first Sunday of November, 1:30 a.m. occurs twice, and a job that triggers on the wall-clock pattern may run twice. Use UTC for cron schedules whenever you can, or use an explicit once-only trigger.
Common mistakes
- Calling 9 a.m. EST in summer.By July, the U.S. East Coast is on EDT, not EST. The hour is the same on the wall clock either way, but the offset from UTC is different (UTC−4 vs UTC−5), and a system that follows the literal abbreviation may resolve the meeting an hour off.
- Treating PDT and MST as different zones in summer. They have the same offset (UTC−7) for those months, so a meeting at 10:00 PDT in Los Angeles is also 10:00 MST in Phoenix, even though the abbreviations differ. The IANA approach handles this without any human translation.
- Forgetting Arizona does not move.A recurring weekly call set up in November between Phoenix and Los Angeles will be one hour later in Phoenix from November to March, then appear "the same time" from March to November.
- Using a fixed UTC offset in code. Hard-coding
UTC−8for "Pacific" will be wrong for eight months of every year. UseAmerica/Los_Angelesinstead and let the time-zone library convert. - Ignoring the southern-hemisphere flip. Sydney is on AEDT in northern winter and AEST in northern summer — the opposite of the U.S. cycle. Two-hour swings appear in any meeting that survives both transitions.
- Scheduling a job at 2:30 a.m. local time. See the spring-forward gap example. Either schedule in UTC, or pick a time-of-day that is not affected by the transition.
Bottom line
Pacific Time has two abbreviations because the federal Uniform Time Act of 1966 (extended by the Energy Policy Act of 2005) splits the year into a standard half and a daylight half: PST in winter, PDT in the much longer warm-weather window. PT is just a way to dodge the question. Arizona, Hawaii, and the rest of Mexico complicate the edges; Baja California stays in lockstep with California. For scheduling and for software, the safest habit is to store IANA zone identifiers like America/Los_Angeles, run conversions through a library that knows the current tzdata, and remember that any meeting between the U.S. west coast and the southern hemisphere will swing by two hours over the course of a year — even though nobody on either end thinks they have changed anything.