San Francisco Time and Why It Gets Weird
Pacific time is UTC-8 standard, UTC-7 during daylight saving. That sounds simple. It isn't, not if you're doing anything that involves scheduling, logging, or syncing across systems. Right now, it's 7:34 AM PST in San Francisco. (Check a live clock if you need exact seconds—the city isn't going anywhere and neither is the timestamp.) The trick isn't knowing what time it is there. The trick is knowing what it *was* five minutes ago when your database committed a transaction, or what it *will be* in three hours when a cron job fires across three servers in three different regions. I used to manage a deployment pipeline for a SaaS product back when we had no observability beyond `print` statements. We ran servers in Oregon, Ohio, and Frankfurt. San Francisco was the office location for the only engineer who could make decisions fast enough. Every time zone transition screwed us up. Here's the thing nobody tells you: Daylight Saving time doesn't happen on the same day everywhere, and it doesn't last the same length. Arizona and Hawaii don't observe DST. Most of Indiana did until 2006. The Pacific zone shifts at 2:00 AM local time on the second Sunday in March, but the Eastern zone shifts at 2:00 AM Eastern—which is 11:00 PM Pacific the night before. So for roughly one hour, the offset between Pacific and Eastern changes from 3 hours to 2 hours. If your app stores times as "Eastern minus 3" and someone queries at 1:30 AM Eastern on that transition night, your calculation is wrong. I found it by accident when a billing report showed charges at 11 PM the previous day instead of 2 AM.
How to Actually Get the Right Time
Use IANA timezone identifiers, not fixed offsets. San Francisco is America/Los_Angeles. Not "PST," not "UTC-8." America/Los_Angeles. The difference matters because rules change. In 2007, the US moved DST start dates. If you're using a system that hardcodes "second Sunday in April," you're already wrong for anything after March 2007. In practice, here's what works: Store everything in UTC internally. Never store local time in a database column meant for comparison, sorting, or audit trails. This is the single most important rule and the one people ignore most often. I've seen production systems where "created_at" was stored as a string in the local timezone, and debugging date-range queries became a full-time job for whoever inherited it.
Format for display only at the edges. Your API returns UTC timestamps. The frontend converts to the user's local timezone using the browser's Intl.DateTimeFormat or equivalent. Never do timezone conversion on the server unless you specifically know the target audience's region and have a business reason to do so. Watch the transition windows. If you're processing events that happen near 2:00 AM local time during a DST change, you'll get either a skipped hour (spring forward) or a duplicated hour (fall back). For San Francisco in spring, 2:00 AM becomes 3:00 AM. Any schedule between 2:00 and 3:00 doesn't exist. In fall, 1:00 AM occurs twice—once in PDT and once in PST. If your system processes "1:30 AM" without a timezone context, it's ambiguous. I wrote a helper function that normalizes all incoming timestamps to UTC before any business logic touches them. It took about twenty minutes to write and saved me approximately forty hours of debugging over two years.
Get the Full Details
Common Pitfalls
Python's datetime without timezone awareness is a landmine. A naive datetime object has no idea what timezone it's in. datetime.now() returns local time, but datetime.utcnow() returns UTC—except it's still a naive object, which means you can't reliably do arithmetic between the two. Use zoneinfo (Python 3.9+) or pytz if you're stuck on an older version. And for God's sake, stop using time.strftime with %Z and hoping it gives you the right abbreviation. It won't, not consistently. Javascript has its own annoyances. Date.getTimezoneOffset() returns minutes west of UTC, which means it returns positive values for western hemispheres (like +480 for Pacific). The sign convention trips people up constantly. Also, new Date("2024-03-10 02:30:00") is interpreted as UTC by the browser, not local time. If you want local parsing, you have to be explicit about it. Linux systems use the tzdata package. If your server's timezone database is outdated, your system will apply the wrong rules for historical dates. I encountered a case where a backup system scheduled a job for 3:00 AM on a Sunday in November, and the job ran at the wrong time because the container image hadn't been rebuilt since 2019. The DST transition rules had changed in the IANA database. Updating tzdata fixed it.
What to Use Instead of Guessing
If you need to know the current time in San Francisco with precision, don't calculate it yourself. Query an NTP server, or better yet, use a library that does. The moment-timezone library for JavaScript, python-dateutil with zoneinfo for Python, and java.time.ZoneId.of("America/Los_Angeles") for Java all handle the transitions correctly if you give them the right identifier. For a quick check without writing code, date +"%Z %Z %:z" in a terminal with TZ=America/Los_Angeles will show you the current offset and abbreviation. Or just go to timeanddate.com and type in San Francisco. Nobody's going to judge you.
