Converting PDT is simpler than people make it, but that simplicity hides a few traps that will bite you if you aren't paying attention.
Pacific Daylight Time is UTC-7, and it runs from the second Sunday in March until the first Sunday in November. Pacific Standard Time, which is UTC-8, takes over after that. That two-hour swing is why most mistakes happen, and why I have sent calendar invites to meetings that didn't exist in half the world at least three times in my career. It sounds like a question someone types into a search bar when they are confused by a timestamp, but the real answer is about understanding the zone and knowing when your tools fail you. PDT is a time zone offset, not a calendar rule. The offset stays constant throughout the daylight period, but the start and stop dates shift slightly every year because they depend on Sundays, not fixed dates. In 2024, for example, PDT began on March 10 and ended on November 3. In 2025, those dates move to March 9 and November 2. Your spreadsheets and scripts need to account for that drift if you are building anything that generates schedules automatically. I once built a conversion tool for a logistics team that pulled departure times from a database and displayed them for stakeholders in six different countries. The tool worked perfectly for three months, then started showing arrivals that were an hour off. It turned out the script was hardcoding the DST transition dates based on 2023 rules. When the US adjusted the window slightly in 2024, the script had no way to know. The fix was straightforward, but it cost me about four hours of debugging because the affected shipments were small enough that nobody noticed the error immediately. After that, I switched to using IANA timezone data instead of hardcoded offsets, and I stopped trusting any system that does not pull from tz database versions.
The most practical way to decode PDT depends on what you are actually doing. If you are just checking what time it is right now in Los Angeles, San Francisco, or Seattle, you subtract seven hours from UTC. A meeting at 14:00 UTC is 07:00 PDT. A conference call at 20:00 UTC is 13:00 PDT. That is the basic math. The part people mess up is the direction of the conversion when the other person is in PDT and you are not. If a colleague in Seattle sends you a meeting at 09:00 PDT and you are in London, you add seven hours, not subtract them. Add when you are moving toward UTC, subtract when you are moving away. That heuristic has saved me more times than I can count. For global professionals who deal with this daily, the real work is not the arithmetic. It is the coordination around the transition periods. The two weekends each year when clocks change are where schedules collapse. A project manager in Tokyo coordinating with a team in Vancouver will see a one-hour compression during the spring transition and a one-hour expansion in the fall. During those windows, a recurring daily standup that usually sits at a comfortable middle ground can suddenly land at 3:00 AM for one side or 11:00 PM for the other. I learned to pause all recurring invites four days before a transition and manually verify the new slot for everyone involved. It adds about fifteen minutes of work per cycle, but it prevents the kind of miscommunication that cascades into missed deadlines. There are a few tools worth knowing about, and most of them are free. The IANA Time Zone Database is the gold standard if you are working in code. Libraries like pytz for Python or moment-timezone for JavaScript reference it directly. If you need something faster and you are not writing software, just use a site like timeanddate.com or the built-in converter in Google Calendar. Both handle DST transitions correctly and both will show you the exact UTC offset for any date without you having to calculate it yourself. The downside is that neither of those tools will catch edge cases in your own systems. If you paste a PDT timestamp into an internal database that stores everything as naive timestamps without timezone awareness, Google Calendar will look correct while your backend quietly breaks. I have seen this happen in production twice. Both times the fix required a database migration, which is never a quick job.
One thing most people do not think about is how PDT interacts with international date lines. If you are scheduling something between PDT and a region like New Zealand or Fiji, you are crossing not just a time offset but a calendar day boundary. A Friday afternoon meeting in Los Angeles can be a Saturday morning meeting in Auckland. The date changes even though the time difference is only about twenty hours. This matters more than it should when you are dealing with compliance deadlines, payment processing windows, or any system that checks the date rather than the full timestamp. I used to forget this when sending documents with legal deadlines to Pacific partners, and I once sent a filing at 5:00 PM PDT thinking it was still the business day everywhere. It was already past midnight in New Zealand, and the receiving system had already rolled over to the next day. After that, I started always converting to the recipient's local date first before marking anything as urgent. If you need a quick reference, here are the core offsets you should memorize so you do not have to look them up constantly: PDT is UTC-7, PST is UTC-8. Los Angeles, San Francisco, Seattle, Portland, Phoenix, Las Vegas, and Anaheim all observe PDT except Phoenix, which stays on MST year-round and does not participate in daylight saving time at all. That exception matters. If you are coordinating with someone in Phoenix and you assume they shift with PDT, you will be off by an hour every spring and summer. I spent an entire quarter sending invites at the wrong time to a partner in Scottsdale before I realized the issue was the locale, not the math. The bottom line is that PDT itself is trivial to understand. The difficulty is in the operational details: transitions, tooling, exceptions, and the fact that half the world still treats time zones as something you can hardcode. If you build your workflow around immutable UTC internally and only convert to local time at the presentation layer, you will save yourself most of the headaches. Anything else is just waiting for a DST change to expose the flaw.
Get the Full Details
