Understanding How Time Works In California
Pacific Time runs on UTC-8 during standard time and UTC-7 when daylight saving is active. That's the basic math most people need, but the actual implementation is messier than the Wikipedia entry suggests. California observes DST from the second Sunday in March through the first Sunday in November, same as the rest of the Pacific Time Zone states and provinces. Arizona doesn't follow this pattern. Hawaii doesn't either. If you're scheduling across those zones and assume uniformity, you will make mistakes. The thing that actually trips people up isn't the offset itself. It's the transition windows and the edge cases around them. I ran a distributed system for about five years where we had service calls landing in LA, Seattle, and Phoenix on the same schedule. We lost two production deployments to misconfigured cron jobs during DST spring-forward weeks because our monitoring assumed all three nodes shifted at the same moment. They don't. The U.S. changeover happens at 2:00 AM local time in each zone, which means Seattle moves its clocks before Phoenix does because they're in different time zones to begin with. If your scheduler uses absolute UTC timestamps internally, you're fine. If it stores local time strings and relies on system-level time zone databases without careful validation, you're asking for trouble. Current offset for Los Angeles changes depending on the date. Right now during DST, the city sits at UTC-7. Before March or after November, it drops to UTC-8. The changeover is not instant across every application on every machine. I've seen servers report stale offsets for several minutes after the transition because the time zone database hadn't been updated or because the NTP sync was lagging. This matters more if you're dealing with financial timestamps, compliance logging, or anything where a sub-minute discrepancy causes audit flags.
How I Actually Handle This In Practice
Never store local time in your database. Store everything in UTC and convert at the presentation layer. This eliminates about 90% of the confusion around DST transitions, summer/winter offset changes, and cross-zone scheduling. When I had to build a booking system for a multi-time-zone audience, the initial version accepted local time strings from the frontend and stored them as-is. That was a mistake. A user in San Francisco could book a 3 PM call, the timestamp would be stored as "15:00" without any zone information, and then a user in Phoenix would see that same "15:00" on their screen thinking it was their local time. It wasn't. It was Pacific time. The misalignment caused roughly 12% of support tickets in the first quarter after launch. We switched to storing UTC and converting client-side with explicit IANA zone identifiers like America/Los_Angeles and America/Phoenix. Ticket volume dropped to under 2% within two months. If you need to work directly with the local time for any reason, use the IANA time zone database rather than relying on abbreviations like PST or PDT. PST can mean Pacific Standard Time or Philippine Standard Time depending on context. PDT is similarly ambiguous in some systems. The IANA identifiers are unambiguous and portable across operating systems, programming languages, and database engines. PostgreSQL handles this natively with its TIMESTAMPTZ type, which stores in UTC and converts on output based on the session's time zone setting. MySQL requires you to be more explicit with CONVERT_TZ() functions and a properly loaded time zone table. SQLite doesn't handle this well at all. You'll want to do the conversion in application code before hitting the database if you're using SQLite.
Common Pitfalls That Nobody Warns You About
DST transition days are when most failures happen. The spring-forward night loses one hour. The fall-back night gains one hour. Any process that runs hourly and doesn't account for the missing or duplicated hour will behave unpredictably. I once had a batch job that processed logs by hour. During the spring transition, it skipped an entire hour of data because the hourly trigger never fired for 1:30 AM Pacific—that time simply didn't exist. The fall transition duplicated processing because the hour was touched twice. We fixed it by switching the job to use UTC internally with a rolling six-hour window that included the transition boundaries, which meant we always captured the full dataset regardless of how many times the local hour appeared or disappeared. Another issue people overlook is browser-based time zone detection. JavaScript's Intl.DateTimeFormat and Date.prototype.toLocaleTimeString() rely on the user's device settings, which are frequently wrong. Travelers, people with multiple homes, and anyone who hasn't updated their phone since the last time zone rule change will report incorrect offsets. I built a time picker for a scheduling tool that defaulted to the browser-reported zone. About 6% of users were consistently off by one hour during DST weeks because their devices were still on standard time or vice versa. We added an explicit zone selector with a list of major cities and let the user confirm their offset. Accuracy went from roughly 94% to 99.7%.
Get the Full Details
When This Approach Breaks Down
The IANA database approach works for virtually all practical purposes, but it has real limitations. Historical time zone data before the 1970s is spotty and often contradictory. If you're processing records from before 1970 that include timestamps, you should expect some records to have uncertain or incorrect offsets. California adopted DST inconsistently during World War II and the 1960s before the Uniform Time Act of 1966 standardized it. There are documented periods where the entire state was on DST year-round for war efforts, then reverted, then experimented with different start dates. Legacy systems that reference dates from that era will produce ambiguous results unless you define a policy for handling historical ambiguity, which most people don't bother doing. Second, the U.S. time zone rules change occasionally. Congress has amended the DST start and end dates before, most recently with the Energy Policy Act of 2005 which pushed the start earlier and the end later. There have been repeated legislative proposals to make current DST permanent, which would effectively eliminate the biannual clock change for participating states. If you're building a long-lived system, assume the rules could shift again. Store your transition logic in a configurable layer rather than hardcoding dates, and plan to update it when the government changes the schedule. The IANA database gets updated regularly, but if your deployment pipeline doesn't pull in those updates automatically, you'll be running on stale transition dates. For most people just trying to figure out what time it is in Los Angeles right now versus New York or Chicago, the answer is straightforward: Pacific Time is three hours behind Eastern and two hours behind Central during standard time, and the same offsets hold during daylight saving because all three zones shift together. The complexity only appears when you're building systems that process these times programmatically or when you need historical accuracy. For casual use, knowing the current UTC offset and whether DST is active is usually sufficient. Check your device's clock settings, confirm it's set to America/Los_Angeles, and you'll rarely go wrong.
