Daylight Savings Time Software Problems: Who Is At Fault?
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. 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 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 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, 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
daylight savings time
This is not a "massively complex undertaking" - software itself is more complicated than anything else mankind designs - this is a trivial task of changing the time, and it is only 7 years since Y2K.
Whose to blame? People who keep buying mediocre and bad software. Software salesman continue to make a mint, resources to test, redesign and fix software get cut, and vendors without good salesman who put resources into quality products are ignored. When a badly made product breaks, everyone gets mad for a while, and then keep buying the same stuff from the same vendor. If consumers and corporate buyers made quality a higher priority, you can bet software companies would.
Whee
Sirius should be spanked, long and hard. The DST change law was passed a year before the devices in question hit the market. For that matter, who the hell designs a piece of consumer electronics with a clock whose clock can't be set by the user? And posting a technical bulletin two days before the event, well that's pathetic.
I blame the software manufacturers. We've had almost two years to implement this change. Two years people. Whether your solution is flexible or not, you should have been able to compensate for the change in the last two years...
For anyone running Microsoft software that will be affected by a problem with a DST change, here's your solution: Open the Windows clock, go to the timezone tab. Uncheck the box marked "Automatically adjust clock for Daylight Savings Time." Now, push out a group policy to force network machines to synch their time with your local time server. At 2am or whenever the hell the pinheads in DC have decided the time changes, you get up, change your server's time, have a beer and go back to sleep. That'll be $4,000 thankyouverymuch.
--Ed
Oh yeah, Hi Dan!
Oh if it were so simple
My computers get their time from the server, but the fact that MS didn't issue a hotfix for Win2K assured that those machines would not get DST correct. A few utilities fixed this, but they were not part of the automatic updates.
The fix was not that difficult, and was detailed in an MS KB article.
The real problem is DST. We should just get rid of it, and learn to conduct our daily business by the sun. The day should start after dawn. It's entirely feasible. We have computers and devices that can calculate when the sun rises, and can issue an alarm at that time. The start-of-day can be offset from dawn. You get 2 hours of "morning" time to yourself. Then you get 8 hours or so of work, followed by "evening".
If the clock "breaks", we can rely on the sun and our circadian rhythms.
Solar time isn't the answer
At least I don't think it is. Anybody who cares to listen knows that I'm quite willing to rant against DST at the drop of a hat. Standard Time, on the other hand, is a boon to mankind.
My experiences with working on the railroad may have left me biased, but I can't imagine trying to conduct even basic family business where everybody sets their watch by solar noon. Every few miles you end up a few minutes further out of sync. No, I think standard time, with most time zones incrementing by a full hour, makes the best of an awkward world.
And I'll stop now, before I start ranting against DST.
Clarification
The clocks would not be changed. They'd always be on standard time, as usual. Time zones would continue to exist, and time would be quantized. Business hours, however, would be malleable, based on the time when the sun rises.
The point of DST was to increase the amount of useful daylight. Going with a sun-based business day, where the start of the official business day is relative to dawn, would optimize for this goal.
For example, if the sun rises at 6am, then you can say the official business day starts at 9am. If it rises at 5am, then it starts at 8am. If it rises at 7:00, then business starts at 10:00. Businesses could individually decide when the degree of quantization they wish to support. Perhaps they'd use half-hours.
It would create confusion for businesses, but, only at the start and end of the day.
That's a terrible idea.
That's a terrible idea. You think it's complicated now.
You're doubling or tripling the number of effective time changes. "Oh, the sun rose today at 7:01 instead of 6:59 so instead of having an hour before work I now have 90 minutes?" And for people a few towns west it's now rising at 6:59 instead of 6:57 so they still start work at 9:30 (half hour quantization) and I start at 10?
DST, Unicode, Timezones, DNS, l10n, I18n ...
It seems part of the problem is that most software comes from - or at least has it's origin - in the USA or UK.
In a software world treating everything beyond A-Z,a-z,0-9 as a mysterious black art it is no wonder "modern software" fails an trivial tasks like DST.
It would be wonderful having a senior manager at Microsoft with special characters in his surname and a wife in Nepal being in a timezone +5:45 UTC. His mother might be a Japanese women speaking and reading only Japanese, his uncle could be colorblind, his sister being handicapped and not able to use a mouse, his brother might run a small company struggling to create some piece of a/v equipment for DJs and being threatened by obscure patents....
Well... just an idea...
Lesson Learned
The author of the article asked for lessons learned from the DST change this year.
We learned that we had inadvertently saved ourselves a whole lot of work by storing dates and times in LOCAL time in our DB.
That way, we could apply the appropriate patches, fire up the applications again and be up and running without much strain.
I had long bemoaned the fact that we didn't use UTC to store dates. If we had, all those timestamps would have had to be adjusted with the change over. But... non-DST timezones would then receive incorrect data.
I've got no conclusions yet on which I'll chose for my next project (local or UTC), but my experiences on DST 2006 will be taken into account.
I'm the Argumentative Colleague...
Basically, my position is that if your product or application is a timekeeper; if that is part of your functionality; then any design that treats DST as a given, or hard-codes it in any way, is poor design.
To expect DST to stay set in stone for the convenience of technology companies, when the measure is a conservation measure less than 40 years old... that's just a lack of proper planning.
Congress didn't enact this "recent" change without an adequate implementation window, either. They were certainly aware of the capacity for disruption and the need for time to adapt. If your underlying design acknowledged the possibility that the implementation dates of DST were subject to change, there was certainly ample time. What I am saying is that any architecture that treated DST as not being subject to change in the first place is at fault. Further, given the generous implementation window, any IT services professional struggling to patch *today* is arguably to blame also.
I certainly agree that there can be a lot of complexity in working out the details of these changes, but to point the finger at congress for the costs incurred is akin to blaming Astronomers for the cost to reprint textbooks that still list Pluto as a planet.
Bottom line: If being "smart" about DST is functionality you are paid to deliver, you have an obligation to deliver it. Any design that for all practical purposes hard-coded DST, was (especially in the wake of Y2K) poorly designed, and quite possibly negligent.
I think there might be fertile ground for a class action lawsuit to that effect.