So You Need to Figure Out a Two-Hour Shift Across the Country
I've been coordinating schedules between the West Coast and Central time zones for years. People get tripped up constantly. The math itself is simple — PDT is UTC-7, CST is UTC-6 — but the real friction isn't in the arithmetic. It's in the edge cases, the partial overlap windows, and the times when the rules change halfway through the year. I'm going to walk through how I handle it now without making it sound harder than it is. During the months when both zones are on standard time, the gap is exactly one hour. When PDT is active but CST has already switched to CDT, the gap becomes two hours. That's the "two-hour shift" most people are actually referring to when they say it. The confusion starts when someone in Chicago says "let's meet at 9 AM CST" during summer, and you assume they mean the old offset. They don't. They mean CDT, which puts them two hours behind you in PDT. You show up an hour late to whatever you think you scheduled. Here's the quick mental model I use now: I don't convert the destination time. I convert the overlap. I figure out what hours exist in both zones simultaneously, and I anchor my scheduling to those hours. Between 10 AM and 6 PM PDT, there's always a clean two-hour window of overlap that maps to 12 PM to 2 PM in CDT. Those are your safe hours. Outside of them, you're working in thin air where one side might have already gone home or hasn't started yet.
I ran into this explicitly last October when I was coordinating a product launch call between our Seattle team and our Dallas office. Someone on the Dallas side had set up a recurring weekly sync at 3 PM "CST." Except October is when DST ends, and Dallas switches first — usually the first Sunday in November, sometimes earlier depending on the calendar. That week, Dallas was already on standard time while Seattle was still on daylight time. The meeting landed at 2 PM PDT instead of the intended 11 AM PDT slot. We missed the entire first act of the demo. I've never let a recurring meeting run on a raw abbreviation again. The workaround was brutal but effective. I stopped asking for time zone abbreviations entirely. I started requiring UTC offsets or IANA zone names — America/Los_Angeles, America/Chicago. Those don't lie. Abbreviations like CST, CDT, EST, EDT are ambiguous by design and they cause exactly this kind of problem. A single string like "CST" could mean Central Standard Time (UTC-6) or China Standard Time (UTC+8). It happens more often than you'd think in crosscountry coordination. For the actual conversion, here's the straightforward part. If you're in PDT and need to know what time it is in CST during standard time, subtract one hour. If you're in PDT and need to know what time it is in CDT during the overlapping daylight period, subtract two hours. Reverse it when you're going the other direction. That's it. There's no secret formula. The reason people screw this up is that they memorize one rule and apply it year-round without checking which variant is active.
I use a simple mental check now before sending any invite: I look at the month. April through November in the US is when DST is active for most of the country. During that window, the PDT-to-CDT gap is two hours. November through March, the gap collapses to one hour because the US falls back but places like Arizona (which doesn't observe DST) and parts of Canada stay put. If the meeting involves Phoenix, forget everything I just said — they're on MST year-round and the math changes again. That's another whole can of worms I won't dig into here. For scheduling tools, I recommend avoiding anything that forces you to pick a time zone from a dropdown and then manually adjust. Use a system that stores everything in UTC internally and only converts for display. Google Calendar does this correctly if you set your default time zone properly. When you create an event, it'll show you both zones side by side and lock in the correct UTC offset. If you're building something custom, store the event as an ISO 8601 timestamp with an explicit offset, not as a naive local time string. The latter will bite you the moment anyone moves across a DST boundary. Here's a practical example I use when training new team members. Say you're in Portland and you want to find a time that works for someone in Nashville. Both cities observe DST. You pick 2 PM Portland time. Nashville is two hours ahead during the shared DST period, so that's 4 PM Nashville. Simple. Now say the same meeting falls on the Sunday when DST ends. Portland is still on PDT but Nashville has already switched to CST. The gap is one hour. Your 2 PM Portland becomes 3 PM Nashville, not 4 PM. If you sent the invite based on the old calculation, your Nashville colleague shows up an hour early and watches an empty Zoom room. This is the mistake I keep seeing. It's not a comprehension problem. It's a complacency problem.
Get the Full Details
If you want something faster than doing this in your head, there are a few tools worth knowing. TimeAndDate.com lets you pick both zones and shows you the exact overlap window for any given day. It accounts for historical DST changes too, which matters if you're scheduling something retroactively or looking back at when a past meeting actually occurred. For a programmatic approach, the date-fns-tz library in JavaScript handles IANA zone conversions cleanly. Python's zoneinfo module does the same thing. Both respect historical DST rules, not just the current year's schedule. The limitations of all of this are worth stating plainly. No amount of tooling fixes the human problem of someone writing "3 PM CST" in an email and meaning something different depending on which year they wrote it. Abbreviations are the root cause. Even sophisticated schedulers can fail if the input is ambiguous. The only real defense is demanding unambiguous time representations in every piece of coordination communication. It's not elegant. It doesn't feel great to be the person who says "please specify the UTC offset" in a Slack thread. But it prevents the alternative, which is showing up to a meeting that doesn't exist at the time you thought it existed. I also learned the hard way that not every region follows the same DST schedule. If your "crosscountry" coordination ever touches Hawaii, Puerto Rico, or any international location, the two-hour rule evaporates entirely. Hawaii is on HAST year-round with no DST. That's a three-hour gap from PDT instead of one or two. Caribbean locations vary by island. The moment you step outside the continental US mainland, every shortcut you've memorized becomes unreliable. I keep a reference sheet pinned in my notes that maps every US territory and common international partner zone to its current UTC offset. It takes thirty seconds to check and saves an hour of damage control.
Bottom line: the conversion itself is trivial. The difficulty lives in the transitions, the abbreviations, and the assumption that what worked last month will work next month. Write down the UTC offset. Verify it matches both sides of the conversation. Don't trust an abbreviation. Schedule during the overlap window when you can. And for the love of anything, stop letting recurring meetings run on auto-pilot through a DST change without checking the new offset. I still get defensive just thinking about that October demo.
