San Francisco Time Zone Everything You Need To Know
If you've ever scheduled a call with someone in San Francisco and ended up on a Zoom at 9 AM when they were still at their desk with coffee, you've already learned the hard way how timezone math works in practice. Pacific Time is straightforward until it isn't, and the exceptions are what actually trip people up. Pacific Time uses UTC-8 during standard time and UTC-7 during daylight saving time. That's the Wikipedia answer. The real answer is that California follows the same DST schedule as the rest of the United States: clocks spring forward on the second Sunday in March and fall back on the first Sunday in November. This has been the rule since 2007, but it wasn't always the case. Before that, the transition dates were different, which is why you'll sometimes see legacy systems or older code that still calculates DST transitions using the old rules from 1987.
Where San Francisco Time Zone Everything You Need To Know Actually Comes From
SF sits in the Pacific Time Zone, one of six official US time zones. The zone itself is defined by longitude roughly between 112.5 and 127.5 degrees west, which puts San Francisco solidly in the middle of it. The officialIANA time zone identifier for this region is America/Los_Angeles, which covers not just SF but all of California, most of Nevada, and parts of Oregon and Idaho. When you're working with databases, logs, or server configs, you should always use the IANA identifier rather than a fixed offset, because the abbreviation "PST" or "PT" carries no timezone information on its own. I spent about three days debugging a cron job in 2019 that was deleting archived log files one hour earlier than intended every March and November. The job was configured with a hardcoded offset of -8 hours from UTC, which worked fine for standard time but broke the moment daylight saving kicked in. The server itself was running in UTC, so the internal timestamps were always correct, but the deletion schedule that fed into it used the system clock interpreted as Pacific Time without any DST awareness. Switching the configuration to use TZ=America/Los_Angeles instead of a raw offset fixed it immediately, and I haven't seen the problem since. The lesson was basic but easy to miss if you're not used to thinking about it: never use fixed offsets for human-readable scheduling. It only causes problems during the transition weeks, and even then only if your code path touches the clock at exactly the wrong moment.
The Two Transition Days That Break Everything
On the day clocks spring forward, February to March, there is an hour that doesn't exist. If your application asks "what time is it" at 2:30 AM Pacific on a DST transition morning, the answer is invalid. Systems that don't handle this gracefully will either crash, skip data, or silently accept the impossible timestamp and store it wrong. On the fall-back day, there are two 2:30 AMs, and the same kinds of problems appear in reverse: duplicate timestamps, double-counted events, or confusion about which occurrence a given log entry refers to. The workaround most people end up using is to do all internal computation in UTC and only convert to local time at the edges of the system, right before displaying something to a human or right after reading a user input. This avoids the entire class of problems because UTC never has DST transitions. You still need to handle the transitions correctly when accepting user input, but at least you're not computing with ambiguous times throughout your data pipeline.
Get the Full Details
Common Pitfalls That Beginners Miss
The first thing people get wrong is assuming that PST and PT mean the same thing. PST is Pacific Standard Time, which is UTC-8. PT is Pacific Time, which is the ambiguous generic label that could be either PST or PDT depending on the date. If your system logs say "08:00 PT" without a date, you can't tell whether that's UTC-8 or UTC-7. Always include the date when recording timezone-aware timestamps. Even better, record the UTC offset explicitly or use the IANA zone name. A second mistake is treating daylight saving time as if it's the same everywhere. It's not. Arizona doesn't observe DST, so during the summer months Phoenix is on MST year-round (UTC-7), which is the same offset as Pacific Daylight Time. If you're scheduling something across the Southwest, Arizona is a special case that breaks any assumption that the entire state of Arizona or the entire Pacific region behaves uniformly. Navajo Nation, which extends into Arizona, does observe DST despite being in the state that doesn't, which adds another layer of complexity that almost no one anticipates. The third mistake is assuming that all servers in a region use the same timezone setting. In production environments, you will routinely find some machines set to UTC, some to the local zone, and some to hardcoded offsets that haven't been updated since the last policy change. I inherited a cluster where half the nodes ran UTC and half ran America/Los_Angeles, and the discrepancy only surfaced when we tried to correlate events across services during an incident. It took about four hours to realize the root cause was a timezone mismatch, not a network issue. The fix was standardizing everything to UTC internally, which is the normal recommendation for any system that handles distributed logging or event correlation.
How to Verify Your Current Timezone Setting
If you're on a Linux or macOS system, run the command tzselect interactively, or check the output of date "+%Z %z" to see the current abbreviation and offset. On Windows, you can check the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. For containerized environments, look at the TZ environment variable, though many Docker images default to UTC regardless of what you might expect. If you're writing code, use a library rather than rolling your own conversion logic. The Python pytz or zoneinfo modules, the JavaScript Intl.DateTimeFormat API, and the Java java.time package all handle DST transitions correctly. Avoid custom arithmetic for anything that involves historical timezone changes, because the rules have changed multiple times over the decades and your code will inevitably get one of them wrong. There are legitimate cases where using a fixed offset like UTC-8 makes sense. If you're building a system that exclusively serves users in one location and you don't need to support historical timezone data, a fixed offset is simpler and less error-prone than full IANA zone handling. Some embedded systems and industrial control software use fixed offsets precisely because they're predictable and don't require periodic database updates when governments change DST rules. The trade-off is that your system will drift out of alignment the next time the region changes its DST schedule, which the US has done a few times in recent history. Most web applications and distributed systems should still prefer IANA zones with UTC-internal storage, because the maintenance burden of tracking rule changes is lower than the bug surface created by hardcoded offsets. The initial setup takes slightly more time, maybe ten to fifteen minutes longer for a team that isn't already familiar with IANA zone handling, but it prevents the kind of edge-case failures that show up during transitions and cost significantly more to debug later.
Quick Reference for Common Conversions
Standard time (roughly early November to mid-March): San Francisco is UTC-8. A 9 AM meeting in SF is 5 PM UTC the same day. Daylight saving time (roughly mid-March to early November): San Francisco is UTC-7. The same 9 AM meeting becomes 4 PM UTC. This one-hour shift is why scheduling tools that don't handle timezone conversions automatically are frustrating to use, and why you should prefer tools that store everything in UTC internally and only format for display at the last possible moment. If you need a reliable source for current and historical timezone rules, the IANA Time Zone Database at https://www.iana.org/time-zones is the authoritative reference. It's maintained by the Internet Assigned Numbers Authority and updated whenever any jurisdiction changes its rules, which happens more often than most people expect.
