The Short Answer
San Francisco sits in the Pacific Time Zone. That means standard time is UTC-8 and daylight time is UTC-7. The rule is simple, but the implementation is where things get messy. Pacific Daylight Time runs from roughly the second Sunday in March through the first Sunday in November. Pacific Standard Time fills the rest of the year. When clocks spring forward at 2:00 AM, they jump to 3:00 AM. When they fall back, they drop from 2:00 AM to 1:00 AM. That one-hour gap repeats every fall, and it breaks more systems than people expect. I've been scheduling logistics across the Bay Area for over a decade. The first time I got burned was in 2016, setting up a recurring cross-country video call at 9:00 AM Pacific for a team spread from San Francisco to Denver. It worked perfectly during PDT in July. Then November hit, the clocks fell back, and my Denver colleague was suddenly joining at 8:00 AM local time while I was still at 9:00 AM Pacific. He missed the first twenty minutes because his calendar hadn't adjusted for the offset shift. I stopped trusting manual scheduling after that. Now I run everything through Python's pytz library or the built-in zoneinfo module in Python 3.9+, converting all times to UTC before storing them, and only displaying them in the local zone at render time. That single change eliminated every ambiguity I'd been carrying around for years.
Here is how the technical side actually works if you are building something that needs to handle this correctly. You store every timestamp in UTC. When a user in San Francisco creates a meeting at 10:00 AM on November 1st, you convert that to 17:00 UTC and save it. When a user in San Francisco later views that meeting, you convert 17:00 UTC back to Pacific time using the correct zone rules for that date. The zone rules automatically apply PDT or PST depending on whether the stored UTC instant falls within the active daylight saving window. This approach means you never have to reason about whether a given date is in DST or not, which is where most bugs hide. The edge case nobody warns you about is the ambiguous hour during fall-back. Between 1:00 AM and 2:00 AM on the day clocks fall back, that hour happens twice. If you pass a naive datetime object without a timezone to a conversion function, the library has to guess which instance you meant. Most libraries default to the first occurrence, which is PDT, but that might not match what the user intended. I always resolve ambiguous times explicitly by checking the original source, and if I can't determine intent, I store the time in UTC immediately and ask the user to confirm rather than silently picking the wrong one. Another nuance that trips people up is that the transition doesn't happen at midnight. It happens at 2:00 AM local time, which means the UTC offset shifts mid-day for anyone who happens to be working across the boundary. A server running in Tokyo that logs events against Pacific time will see its UTC offset change from -7 to -8 at exactly 9:00 AM JST on the transition day. If your logging system caches the current UTC offset and doesn't refresh it, you will get timestamps that are off by an hour for the remainder of that day. I learned this the hard way when a monitoring alert fired at the wrong time because the offset was cached from the morning check and never updated after the spring-forward transition.
If you are just trying to tell people what time something is without building software, the practical workaround is straightforward. Always specify the timezone abbreviation or the UTC offset when communicating across regions. Writing "9:00 AM PST" is better than writing "9:00 AM" when the recipient might assume your local convention. If you are sending invites through a calendar system, make sure the event is created with timezone-aware timestamps. Google Calendar and Apple Calendar both do this automatically, but iCal files exported from some older systems strip the timezone data and hand everyone a naive timestamp that each client interprets differently. The biggest limitation of the current system is that the biannual transition itself remains a source of errors across the board. No tool is immune. Even with proper UTC storage and zone-aware rendering, human-driven scheduling inputs can introduce mistakes, especially around the ambiguous hour. I've seen meeting invites created during the fall-back gap end up an hour off in three different calendar applications on the same computer, each one making a different assumption about which occurrence of 1:30 AM was intended. The only reliable fix is to avoid scheduling anything during that one-hour window entirely, and I keep a standing rule in my team's workflow: no recurring events are created or modified between 1:00 AM and 2:00 AM local time on transition days. For most people just trying to understand what time it is in San Francisco relative to other zones, the useful conversions are that San Francisco is three hours behind New York during both PDT and PST since both zones shift together, nine hours behind London during PDT and ten hours during PST, and sixteen hours behind Tokyo during PDT and fifteen hours during PST. The offset to Europe changes depending on whether Europe has also switched to or from its own daylight saving time, which operates on a different schedule than the US, creating a period each spring and autumn where the transatlantic gap is one hour wider or narrower than usual.
Get the Full Details
The US Congress has discussed standardizing daylight saving time year-round for years, but nothing has passed. Until something changes, the biannual shift stays in place and the quirks I described above remain the reality of working with Pacific Time in the Bay Area. Keep your timestamps in UTC, be explicit about timezone labels in written communication, and avoid the ambiguous hour during transitions. That covers the vast majority of problems people run into.
