Working With U.S. Time Zones Is More Annoying Than It Should Be
Most people think the United States has four time zones. It actually has six if you count the territories and the few oddball areas that don't follow the standard rules. That alone causes enough confusion without getting into daylight saving shenanigans or the fact that some states refuse to participate in the switch. I ran into this first-hand when scheduling a three-way call last year between a team in Phoenix, a team in Indianapolis, and a contractor in Indiana's La Paz region. I assumed Phoenix and Indiana were both on Eastern time because they're usually grouped that way on calendars. They weren't. Phoenix doesn't observe DST, so during the summer months it aligns with Eastern time rather than Mountain. Meanwhile, La Paz is technically in a county that opted for Eastern time under a 2006 petition, but the rest of the state sits in Central. I spent forty-five minutes untangling that mess and ended up just using a spreadsheet with offset columns instead of trusting any app. Never trust any app. The official framework is governed by the Department of Transportation, which defines the boundaries under 49 CFR Part 71. The law says what it says, but the reality is that local municipalities can and do carve out exceptions. The Navajo Nation, for example, observes daylight saving time across most of its territory even though it sits inside Arizona, which ignores DST entirely. That means on a map the Navajo Nation looks like it's on Mountain Standard Time year-round, but from April to October it's actually on Mountain Daylight Time, same as the rest of the country except Arizona. If you're booking a meeting, you can't rely on the state line. You have to know the specific community's opt-in or opt-out status. Here's something most people miss: the boundary between Eastern and Central time doesn't run cleanly along any major geographic feature. It zigzags through Ohio, Indiana, and Michigan in ways that make no intuitive sense. The reason is historical railroads and local preference, not geography. If you're writing software that calculates time zones from a zip code, you will hit these edges constantly and your results will be wrong until you account for them. The same applies to Alabama, where the western third is Central and the eastern two-thirds is Eastern, split roughly along the Black Warrior River basin. Not the county lines. The river basin. I learned this the hard way when a client in Walker County complained their production schedule was running an hour off, and it turned out the county seat uses Central while a small town sixty miles east uses Eastern because of a 1972 local ordinance.
The practical way to handle this is to stop thinking in terms of states and start thinking in terms of IANA time zone identifiers. Use America/New_York, America/Chicago, America/Denver, America/Los_Angeles, America/Anchorage, and Pacific/Honolulu as your reference points. Do not use America/Phoenix unless you specifically need to handle Arizona correctly, because the IANA database marks Phoenix as observing MST year-round, which is technically accurate but easily misunderstood. Honolulu never changes. Arizona never changes. Most of Indiana changed in 2006, but parts of the state are still on Central. Tennessee and Kentucky are split down the middle. If you're building a system that handles U.S. scheduling, hardcode the IANA zone per user location and never derive it from state abbreviations. There's also the cultural rhythm piece that nobody talks about enough. Business hours in New York don't align with business hours in Los Angeles in any meaningful way during peak overlap, which is roughly a three-hour window from 9 AM to noon Pacific. That's it. If you're running a national company, your East Coast team loses half their morning to catch the West Coast, and your West Coast team loses half their afternoon to catch the East. The solution most organizations land on is async-first communication with a mandatory overlap window, usually scheduled between 11 AM and 2 PM Eastern. It's not elegant but it works. The companies that try to force synchronous meetings across all three coasts consistently burn time and lose productivity. One more thing that trips people up: the U.S. does not uniformly observe DST on the same dates anymore. The Energy Policy Act of 2005 pushed the start forward by about a week and extended the end by about a week compared to the old rules. Most of the country switched on the second Sunday in March and returns on the first Sunday in November. But again, exceptions exist. Hawaii and Arizona don't participate. The U.S. territories of Puerto Rico, Guam, the Virgin Islands, and American Samoa follow their own rules. Samoa stayed on American time when it switched from Australian jurisdiction in 2011, which flipped the entire territory from one side of the International Date Line to the other. That was not a trivial logistical event for shipping schedules.
If you need a reference that won't lie to you, use the IANA timezone database directly rather than relying on operating system defaults. OS defaults can drift when a government announces a sudden DST change, which happens more often than you'd expect in the U.S. I've seen this happen with Indiana in 2006 and again when Oklahoma briefly considered a DST split in 2019 that almost went through. The database gets updated promptly. The OS sometimes doesn't. For anyone doing anything serious with scheduling across U.S. time zones, keeping your timezone data current is the single highest-leverage thing you can do. Everything else is just dealing with the mess afterward.
Get the Full Details
