Converting Between Pacific and Central Time: What Actually Works
Pacific Time is UTC-8 during standard time and UTC-7 during daylight saving. Central Time is UTC-6 in standard time and UTC-5 during daylight saving. The difference between them is usually two hours, but it shifts to one hour for part of the year when their DST transitions don't line up. This seems straightforward until you have to deal with it at scale, which is where most people run into trouble. When I first built a system that had to process timestamps flowing between West Coast and Midwest servers, I treated timezone conversion like a simple arithmetic problem. Subtract two hours, done. That was wrong. The issue isn't the math. It's when DST starts and ends, and how different jurisdictions handle it differently from year to year. I spent three days debugging what I thought was a code error before I realized the problem was literally just that the US Congress had shifted DST start dates in 2007 and my hardcoded offsets were still using the old schedule. Here is the practical approach. Stop doing manual calculations. Use IANA timezone database identifiers, not raw UTC offsets. Write your code like this: store everything in UTC internally, convert at the boundaries where data enters and leaves the system. In Python that means using zoneinfo.ZoneInfo with "America/Los_Angeles" and "America/Chicago". In JavaScript, use the built-in Intl.DateTimeFormat with timeZone options, or a library like date-fns-tz if you need more control. Never store a timezone-aware timestamp as a naive local time string unless you also store the source timezone alongside it.
The "tipping" part of this comes up when you are dealing with systems that batch-process data across timezones. Say you have a nightly ETL job that runs at 2 AM Pacific and writes records with Central timestamps. During the spring transition, when clocks spring forward, that 2 AM Pacific time doesn't exist on the day DST kicks in. Your job will either fail or silently corrupt data depending on how your pipeline handles the gap. I encountered this specifically when migrating a payroll processing system. The old system used floating point day-numbers with a hardcoded "-2 hours" offset. When I switched to proper IANA zones, the first month's report showed transactions dated March 11th twice, because Central time skipped that hour but Pacific didn't skip the same one. The workaround was to process the job using UTC as the intermediate representation, then apply each target timezone's rules independently. Instead of converting Pacific-to-Central directly, I converted Pacific-to-UTC and then UTC-to-Central. This eliminated the asymmetry that caused the duplicate dates. It also meant that when Mexico changed their DST rules in 2022 without adjusting the IANA database immediately, my system kept working because the database updates are separate from the conversion logic. There are a few things beginners consistently get wrong. The first is assuming the two-hour gap is constant. It isn't. From the second Sunday in March until the first Sunday in November, the gap is one hour. Outside that window, it's two. The second mistake is treating "Pacific Time" as a single thing. America/Los_Angeles and America/Tijuana have different DST histories. If your data includes Mexican Pacific coast timestamps, using the wrong IANA zone will give you incorrect conversions for roughly two weeks per year.
Another counter-intuitive point: leap seconds are invisible to most timezone libraries. The IANA database doesn't account for leap seconds, and neither does POSIX time. If your application depends on sub-second precision across timezone boundaries, you will lose data during leap second events. This matters more than you might think if you're doing financial timestamping or high-frequency trading logs that cross timezones. For bulk conversions, I recommend using a tool like Unicode CLDR for reference data, paired with whichever timezone library your stack provides as the primary engine. If you're doing this in a spreadsheet rather than code, don't. I've seen people try to build timezone conversion formulas in Excel and end up with off-by-one errors that go undetected for months. Use a script. A short Python script with zoneinfo will handle this correctly in under fifty lines and take about four minutes to write once you've done it once. The biggest limitation of relying on IANA zones is that they reflect legal and political decisions, not scientific ones. Governments change DST rules without warning, and the database ships updates quarterly. If you're building something that needs to predict timezone behavior beyond the current database version, you're on your own. There is no API that guarantees future DST schedules will hold. The only real protection is keeping your timezone data sources updated and writing tests that fail loudly when they drift.
Get the Full Details
If you need to convert a single timestamp, the tz database approach works fine. If you are converting millions of records in a data pipeline, consider precomputing the offset tables for your relevant date range and joining them at query time. This avoids repeated timezone lookups and makes your conversions deterministic and auditable. It also means you can spot anomalies by comparing expected versus actual offsets, which is how I caught that payroll bug in the first place.
