Understanding California Time Zone For Scheduling
California runs on Pacific Time, which is UTC-8 during standard time and UTC-7 when daylight saving is active. If you're trying to schedule a call or set up an automated reminder, getting this wrong means showing up an hour early or an hour late, which is exactly the kind of mistake that makes clients unhappy and team members annoyed. The simplest way to think about it: California is eight hours behind Coordinated Universal Time in winter, and seven hours behind in summer. When it's noon in London, it's 4 AM in Los Angeles during standard time, or 5 AM during daylight saving. You can verify this by checking any world clock app, but don't rely on them alone if you're building something that needs to handle time zones automatically. I spent three weeks debugging a notification system where users in San Francisco were receiving alerts at 3 AM their local time. The root cause was that our database stored everything in UTC, and our conversion logic assumed PST year-round. We had to add DST awareness using the IANA time zone identifier America/Los_Angeles instead of hardcoding UTC-8. This fixed the issue, and it's worth noting that just subtracting a fixed offset from UTC will give you the wrong answer roughly half the year.
There are a few things most people get wrong about Pacific Time that aren't obvious until they cause a problem. First, the United States does not start and end daylight saving time on the same dates everywhere. California follows the federal rule: second Sunday in March through first Sunday in November. If you're scheduling with international teams, remember that countries like Australia and New Zealand also observe DST but on opposite cycles, which means the time gap between California and Sydney can swing by up to five hours over the course of a year rather than staying constant. Second, the transition days themselves are messy. On the spring-forward day, 2:00 AM jumps to 3:00 AM, so any scheduled event between those times simply does not exist. If your system tries to create a calendar entry for 2:30 AM on that day, it will either throw an error or silently convert it in a way you did not expect. In the fall, 2:00 AM occurs twice, which means a job scheduled for "2 PM" could fire at two different UTC moments depending on how your library handles ambiguity.
If you're doing this manually, the practical workaround is to always refer to a source that uses IANA identifiers rather than offset-based names. When you communicate with someone in California, ask them what their local time is rather than assuming. One of my own recurring headaches involved a contractor in Fresno who kept insisting they were "on the same time" as us, but they were actually in the Mountain Time zone despite being in California. There are a few counties in the state that observe MST, and it's easy to miss if you're only looking at city names. For automation, the reliable approach is to store all timestamps in UTC in your database, perform conversions at the presentation layer using a proper time zone library, and label everything with the zone identifier, not the abbreviation. PST and PDT look identical to most people but represent different UTC offsets. Your calendar system should do the same thing. The main downside to relying on any of this is that time zone rules change. Congress has talked about making daylight saving time permanent multiple times, and while nothing has passed yet, the possibility exists. If you build a system that assumes the current DST schedule will remain unchanged indefinitely, you may need to update it in the future. IANA handles these updates through periodic releases of the tz database, but your library needs to be kept current, or you'll be working with stale rules.
Get the Full Details
Bottom line: California is Pacific Time, UTC-8 in winter and UTC-7 in summer, but the devil is in the transitions, the edge cases, and the assumptions people make without checking. Verify before you schedule.
