A colleague stopped by my office today and we had a friendly debate about the challenges that software and hardware vendors are having supporting the impending Daylight Savings Time change in the United States, a change that is mandated by recent legislation. In particular, Microsoft and Sun have had well publicized difficulties, and on another DST software bugs thread on this site, I posted this description of a consumer device whose embedded software will not be patched in time [1]. I'm sure one could do a survey and find a long list of software vendors and hardware manufactures having similar problems.
In my colleague's view, setting aside the question of whether or not this legislation was a good idea, the blame for these problems rests squarely on the shoulders of the software and hardware vendors whose products require patching, support, etc.--they should have seen this coming, they should have designed their products to be more flexible, etc. This is their fault, plain and simple. After all, he says, DST is not a force of nature; it is not embedded in reality at such a fundamental level as something like the Gregorian calendar or the metric system.
On the other hand, commenter Kevin Dean posted recently on a ZDNet thread [2] a view that we should give these vendors a break:
Why is this Microsoft's fault?
Microsoft isn't the only one having problems with this. I opened a case with Sun regarding the availability of their DST-patched Java runtimes and got a resolution to the problem only last week. Now I'm scrambling to get all my client workstations, my application server, and my database properly patched.
The blame for this fiasco lies squarely with Fred Upton, a Michigan Republican, and Edward Markey, a Massachusetts Democrat, for sponsoring the amendment to the Energy Policy Act of 2005. The amount of energy saved is miniscule at this time of year (unlike in summer with its longer days) and the disruption they have caused to computer systems and transportation schedules (especially airlines) is phenomenal.
I, like everyone else, would have loved it if Microsoft could have made things smoother, but this is a massively complex undertaking that every computer software provider is having trouble with and the fault lies squarely with a political system that rewards style over substance.
Again, setting aside the question of the wisdom of the legislation (which is certainly also a legitimate topic of debate), Mr. Dean's position is that the complexity of this issue dictates that we should cut software vendors and hardware manufacturers a break on this.
Is there a way that vendors and designers could have avoided this? Or is this an inescapable problem once you decide to cross the boundary into making your software "smart" about changing the time automatically relative to DST, rather than just keeping your software "dumb," like my microwave oven, which I have to change manually twice a year.
In a DST software bugs [3] post I wrote in April of 2006, before I had heard anything about this impending DST start date change, I took the position that we have ourselves to blame for difficulties with software bugs and system synchronization problems related to DST, because after all, the time changes happens twice a year, every year, and we should not be caught with our pants down, beepers going off, support phones ringing, every time it happens. However, I think the context of that discussion was a little different (but maybe not); Scott Rosenberg posted similar sentiments recently [4], more from a support/logistics standpoint.:
Back when my job as Salon managing editor involved overseeing our daily production, I noticed that, every spring and fall, almost without fail, our publishing system would experience a glitch of some kind on the weekend that the clocks got moved forward or back — nothing serious, mind you, but enough to throw a wrench in the works of our site updates. It wasn't a single bug, but some sequence of related bugs, so we'd fix one and then six months later something else would happen. Eventually we got in the habit of just making sure that one of the developers kept a close eye on things when that weekend rolled around. It was prudent.
In the same post, Rosenberg speculates that perhaps these kinds of challenges are related to something deeper:
It seems that this is one of the unexpected consequences of living in a world operated by software: new danger zones lie where human abstractions — borders, measurements, languages — change or conflict or fail to behave as expected. Clocks and calendars and maps are no longer just assists for human understanding; they are symbols at the heart of systems upon whose performance lives depend. I suppose this started with the first railway schedule, but with the dateline-addled F-22 it has entered a whole new realm of disconcert.
What do you think? Are there fundamental lessons here that software designers and companies should be heeding? Are there some products or manufacturers that got this *right*, who have not experienced difficulties with the great 2007 DST transition? If so, what can we learn from their example?
Thanks for reading,
Dan