Setting Up Reliable Pacific Time on Your Systems
Pacific Time is UTC-8 standard and UTC-7 during daylight saving. That part is straightforward. What people mess up is assuming their servers just need a timezone string set and they are good. They are not. I have watched teams spend three days debugging timestamp issues that boiled down to one server never updating its DST transition rule file. Here is how you actually do it right. The foundation is getting the timezone database correct on every machine. On Linux, that means installing tzdata and symlinking your system clock to America/Los_Angeles. Don't use shortcuts like PT or PST. Those are ambiguous because PST implies no daylight saving, and PT isn't a valid POSIX timezone identifier on most systems. Use the full IANA name. I ran into a real problem last year where a batch processing job was reading timestamps from a log file. The job ran fine in our staging environment but produced off-by-one-hour results in production. The issue was that our dev server had been patched with a newer tzdata release while the prod server was still on an older version from six months prior. The 2024 DST change had shifted by a few minutes in some edge cases across different tzdata versions. I resolved it by forcing both environments to the same tzdata version using dpkg-reconfigure --priority=low tzdata after explicitly pinning the package version. You should do the same across your fleet.
For NTP synchronization, the tricky part is that the Pacific coast has excellent upstream options. You should be running NTP against stratum-2 servers that are geographically close. The University of Colorado and UC Berkeley both operate public NTP pools nodes that are under a millisecond away from Los Angeles. Point your /etc/ntp.conf or chrony.conf at clock.cnri.reston.nasa.gov and a few pool entries from pool.us.pool.ntp.org iburst. The iburst flag cuts initial sync time from around 64 seconds down to roughly 8 seconds, which matters when a server boots up cold. There is a nuance most people miss. When your system is within 128 milliseconds of the true time, NTP stops doing rapid corrective jumps and starts doing gradual slewing. If you manually override the clock by more than 1000 seconds using date or hwclock, NTP will discard your adjustment and not sync for several minutes. I learned this the hard way when a colleague ran a one-off script that set the system clock forward by an hour for a test and then forgot about it. The next hour, every scheduled task that depended on wall-clock time was running an hour early. The fix was stopping the NTP daemon, setting the clock manually with clock -s, and then restarting the daemon so it would accept the new baseline immediately. If you are running containers or Docker-based workloads, the timezone information does not automatically carry over. Container images often ship with a minimal OS that has no tzdata installed at all. The workaround is to either mount the host's timezone file into the container at /etc/localtime or bake it into your Dockerfile with a command like ENV TZ=America/Los_Angeles followed by ln -s /usr/share/zoneinfo/$TZ /etc/localtime and installing tzdata. But here is the catch: if you do that in a multi-container orchestration setup and the underlying host updates its tzdata while containers are running, the containers keep using their baked-in copy and silently drift into the wrong offset when DST changes.
For high-precision use cases like financial trading or distributed logging where sub-millisecond accuracy matters, standard NTP is not enough. You need PTP, the Precision Time Protocol defined in IEEE 1588. A properly configured PTP grandmaster on a local switch can push timing accuracy down to single-digit microseconds across the LAN. I set this up for a client who was correlating trade timestamps across three buildings in downtown LA. Their original NTP-based setup had a variance of around 40 milliseconds between nodes, which made it impossible to reliably order events. After deploying a PTP-capable switch and configuring the endpoints, the variance dropped to under 5 microseconds. The downside is that PTP requires specific hardware support and you cannot just install it on any machine. It also fails completely if your network topology involves wireless links or variable-latency WAN hops, because the protocol assumes symmetric path delays which you simply do not get over WiFi or cellular backhaul. Windows systems in the LA area follow a different rule set for daylight saving. Microsoft maintains its own DST schedule which historically has diverged from the IANA rules that Linux uses. In 2007, when the US changed DST start and end dates under the Energy Policy Act, Linux systems updated through tzdata patches while Windows required a separate registry update from Microsoft. I once spent half a day tracking down why timestamps from a mixed Windows-Linux environment had inconsistent offsets during the 2016 transition. The Windows boxes were applying the new schedule correctly, but one server was still running an unpatched 2003-era registry key that defaulted to the old DST rules. Make sure your Windows machines have the latest time zone definition updates installed through Windows Update, and verify them with the tzutil /l command to confirm they are set to Pacific Standard Time with the correct bias values. Database servers need special attention. PostgreSQL stores timestamps in two modes: timestamp without time zone and timestamp with time zone. If you define your tables using the plain timestamp type and rely on your application layer to handle timezone conversion, you will eventually have a problem. The safe approach is to store everything in UTC in the database and convert to Pacific time only at the presentation layer. If you must store local time for compliance reasons, use the timezone-aware type and set the session timezone explicitly with SET TIME ZONE 'America/Los_Angeles'. This reduces the chance of silent bugs where a query returns the wrong hour because the session inherited a different timezone setting from a connection pool.
Get the Full Details
MySQL has a similar but slightly different issue. The server has a global time_zone variable and a per-session variable. If your application opens connections from a pool and assumes they all share the same timezone, but some connections were created by code that ran SET time_zone differently, you will get inconsistent results. I check this by running SELECT @@global.time_zone, @@session.time_zone from my application health checks. If the values don't match what I expect, the connection might be stale or misconfigured.
Common Pitfalls That Waste Hours
The most frequent issue I see is teams treating timezone as an application setting rather than an infrastructure concern. You need timezone configured consistently at the OS level, in your container images, in your NTP/PTP setup, in your database, and in your application code. A mismatch at any one of those layers will cause intermittent failures that are nearly impossible to reproduce in a single environment. I recommend auditing your timezone configuration across all layers during infrastructure setup rather than after a bug report comes in. Another issue is assuming that "Pacific Time" is the same as "Los Angeles Time." It is, but the IANA identifier matters more than the colloquial name. Some regions in Mexico that share the Pacific coast observe different DST schedules than the US. If your application serves users in Tijuana or other Baja California cities, those areas follow the same UTC offset as Pacific Time but their DST transition dates can occasionally differ from the US schedule. I learned this when a user in Tijuana reported seeing dates shift by an hour relative to their US-based coworkers. The fix was using the America/Tijuana IANA zone for Mexican Pacific coast users instead of America/Los_Angeles. Server logs are another area where timezone mistakes hide. If your application writes logs in local time but your log aggregation system expects UTC, searching across time ranges becomes a guessing game. I always configure my logging framework to output ISO 8601 timestamps with explicit timezone offsets, like 2024-03-10T14:32:00-07:00. This way there is no ambiguity regardless of what timezone the log aggregator interprets the data as.
If you are managing this at scale across dozens or hundreds of servers, consider a centralized time management policy. Push the tzdata version, NTP configuration, and timezone setting through your configuration management tool. I use Ansible playbooks that pin tzdata to a specific version, configure chronyd with the appropriate pool servers, and set the timezone on every node. This eliminates the version drift problem I described earlier and makes it trivial to audit what every server is using. There is no single perfect solution for every scenario. PTP gives you microsecond precision but needs hardware support. NTP works everywhere but tops out around a millisecond. Application-level timezone handling is flexible but easy to get wrong. Pick the right tool for your accuracy requirements, document your choice, and make sure every layer of your stack follows the same decision. That is where most people fall short.
