Datetime Hell

May 30, 2012

I remarked on Twitter that dealing with daylight savings time is the worse programming problem imaginable. I thought I'd expand a little bit on what I meant. First, as a technical challenge, daylight savings time, or date math in general, is tricky, full of edge cases, and potentially error prone. That's not to say a smart programmer with some time and decent references on date and time standards can't get the job done. The problem is that because these date and time issues cut across two other tricky areas, geography and law, even success is temporary.

Have a bug free daylight savings time aware process? What about in 2015 when some governing body somewhere changes the law? What if someone on a Pacific island starts using your software? So here's an example of a programming problem that even in the best case is never really finished/solved.

Also, the structure of the problem is such that there really isn't any kind of clever algorithmic solution. The best one can do is keep a database of all the relative time zone shifts and hope to keep it up to date. Luckily, somebody has usually already (to the extent possible) solved that problem.

Finally, the end result of doing all this date math is avoid the inevitable problems that result from having incorrect date/time tracking somewhere in your process. One usually isn't delving into dates and times to add a new feature, one is usually just preventing/fixing bugs. There's little or no payoff for success.