I haven’t yet met anyone who really likes Daylight Savings Time (DST).  Every spring, everyone complains about losing an hour of sleep.  Then you walk through your home and get annoyed by the clocks that aren’t updated automatically.  You get even more annoyed when you have a clock that should’ve been updated automatically but wasn’t, or it somehow got updated incorrectly.

Anyone who has colleagues, family, or friends overseas knows that DST is more complicated than that.  Other countries might or might not participate in DST, and the dates on which they change their time are not the same.¹  When you’re trying to book a meeting or make a telephone call, there’s a few weeks every spring and autumn where you double-check to make sure that you’re not doing it at the wrong time.

DST is a massively complex beast.  In the US, it wasn’t until 2007 that the dates for the time change were standardized across the country².  Before that, states and localities could opt out of DST, although you should note that Arizona and Hawaii still don’t observe it.³

“That doesn’t sound too bad,” you’re thinking to yourself right now.  There’s not a lot of error conditions to be had here.  You could get the date itself wrong, but it’s now standard enough that this isn’t too likely.  You could get the time zone wrong, which is probably most likely to be a concern if you’re close to a time zone boundary or if you’re in one of the places that doesn’t observe it.  Both of these are probably not going to require a lot of engineering effort.

And it’s not, so long as you’re only dealing with the US. But now pause and consider: as of this writing, there are 196 countries in the world⁴.  Each of these countries potentially has their own dates for recognizing DST.  For the countries which observe DST, the dates on which they do so might or might not be standardized, or might be standardized but get moved around if a local government decides to make a small tweak that year.  Localities within these countries also can choose not to observe it.  Don’t forget that the northern hemisphere is observing DST in one direction, and the southern hemisphere is observing it in the other direction.  While you’re at it, realize that “Pacific time” isn’t just the name of a time zone in the US.  Wikipedia has a huge page about daylight saving time by country, which gives you an idea of the complexity of this issue.⁵

All of this is complex enough when we’re thinking about a single clock that needs to update.  Let’s add in another layer of complexity: client/server.  Your computer has its own internal clock, and it updates against a time server somewhere.  That cell phone in your pocket has at least two time sources.  It’s got its own internal clock, and it’s also getting the time from the nearest cell towers.  Your mail application gets its time from the local computer, and it’s also communicating with the mail server and getting items there that are timestamped.  The examples here are all but endless.

In software engineering, we talk about “edge cases”.  An edge case is a problem that occurs when you’re at the outside the usual operating parameters.  DST is a rat’s nest of edge cases.  You can come up with a dozen of them without even trying hard.  Anyone who’s worked on an application that deals with this has a horror story about the year Venezuela changed their dates for DST at the last minute, or somehow one server didn’t get the latest code, or a million other edge cases.

I have to wonder: how much engineering time gets wasted on DST every year?  Just think of all of the tech companies that have to deal with this: any company that makes a mail or calendar application (IBM, Microsoft, Apple, VMware, …), every mobile phone provider (AT&T, Verizon, T-Mobile, …).  Maybe the tech industry could come together to abolish DST and succeed where so many others have failed.