Converting Pacific Time to Central Time
PST stands for Pacific Standard Time, which is UTC-8. Houston, Texas sits in the Central Time Zone, which is UTC-6 during standard time and UTC-5 during daylight saving time. So 2 PM PST converts to 4 PM in Houston when both zones are on standard time. If Houston is on daylight saving and PST is still on standard time, it becomes 5 PM. Most of the year both zones observe DST, but they don't switch on the exact same days, which creates a messy three-week window every spring and fall where the offset flips from 2 hours to 3 hours. The method is straightforward. Take your PST time and add 2 hours for the base conversion. Then check whether Houston is currently observing daylight saving time. If it is, add an extra hour. That gives you the correct Central Time. I use a simple mental rule: if it's between March and November, it's usually +3 hours. Outside that window, it's +2 hours. But that's where people get tripped up. I run a scheduling operation that books calls between West Coast and Texas clients, and one spring I lost about two weeks of miscommunication because the US changed DST rules under the Uniform Time Act amendments in 2007. The old rule was first Sunday in April through last Sunday in October. The new rule shifted it to second Sunday in March through first Sunday in November. For a few years after that change, the overlap period where PST and CDT coexisted moved earlier each year. I had a whole quarter of recurring meetings shifted by an hour because I was using the old offset schedule in my head. I fixed it by setting up an automated checker in our booking system that pulls the current UTC offset for both zones from the IANA timezone database instead of hardcoding anything. That cut down manual checks from roughly 10 per week to zero.
If you need to do this conversion frequently, the most reliable tool is worldtimebuddy.com or even just searching "2 PM PST to Houston time" in a search engine, which will show you the live conversion. For programmatic access, the `pytz` library in Python or the built-in `zoneinfo` module in Python 3.9+ handles this cleanly with `ZoneInfo("America/Los_Angeles")` and `ZoneInfo("America/Chicago")`. I've seen people hardcode the +2 or +3 offset into scripts, and that approach breaks every time the clock changes. It's worth the extra five minutes to set it up properly the first time. The main pitfall is assuming PST and CDT can't coexist. They do. Between roughly the second Sunday in March and the first Sunday in November, the Pacific zone is on daylight saving (PDT, UTC-7) while the Central zone is also on daylight saving (CDT, UTC-5), making the offset +2 hours. But right before DST starts in March and right after it ends in November, there's a brief window where one zone is on standard time and the other is on daylight time, creating a +3 hour difference. If you're scheduling something during those two to three week transitions, verify the exact date. A calendar invite sent at 2 PM PDT in early April goes out as 5 PM CDT, not 4 PM. Another thing most people miss: not all of Texas is on Central Time. The western tip of the state, including counties around El Paso, observes Mountain Time. If someone says "Houston time" but they're actually calling from El Paso, your conversion is off by an hour. It happens more often than you'd expect on customer support calls.
For a quick reference chart: 2 PM PST converts to 4 PM CST, 5 PM CDT depending on the season. If you want a one-page printable version, most government timezone converter pages let you print or export, or you can just screenshot the current conversion from timeanddate.com. I keep a small lookup table pinned in our team's shared doc that covers the two DST transition windows each year. It takes about two minutes to update and saves us from the awkward "wait, is it 4 or 5 PM?" back-and-forth.
Get the Full Details
