I just received an email to remind me that the United States government made some changes to when Daylight Saving Time begins next year (Link to Californian State page but the principle is the same)
The stated reason is to reduce energy consumption.
However, I wonder if those implementing this change have any idea what a massive cost has been imposed on the world economy?
Just look at a list of the affected IBM software products.
Or the adjustments required by users of Microsoft products.
Or Sun...
The same search for Oracle (changes to dst 2007 site:oracle.com) yields nothing official-looking. Boy are their customers in for a shock!
And that's just some major software vendors (and Sun... ho ho). We can add in the impact on the countless independent software vendors and businesses around the world with home-grown software.
Add in the costs of missed meetings, VCRs recording the wrong shows and the effects on cell-phones and car radios and more and you quickly see quite how much work is involved in dealing with this change.
It's good to see that organisations are getting on top of this (well, some of them are...) But I think the true cost will prove to be far higher than anyone would have predicted when passing this change to the law.
[Usual disclaimer: I'm speaking for myself and not my employer. My opinions are my own. I have no idea whether my employer regards this change to DST positively or negatively]
9 comments:
Time zone details are always subject to change; for example this year there was a (sadly defunct) proposal to move England to +1. If software makes these settings hard to update, isn't that a deficiency in the software?
As ever, it's a reminder to externalize your reference data -- a particular bugbear of mine.
Ben - I think the widespread (and similar) response from the vendors I examined would suggest that this problem is harder than you're giving them credit for. As far as I know, significant zone definitions change rarely (in the sense that the rules change rarely).
Henry - very true... and I'm sure this stuff is externalised in many products across the industry but it is, of course, only part of the problem.
Even if all products were designed in that way, there would still be a large piece of work that every single company had to do to go through their inventory of software and determine if a patch was required, apply the patch, test, etc, etc, etc.
When you add in legacy code, the frightening body of undocumented and unsupported code in production and embedded code that is almost impossible to modify, things get very nasty :-(
Rule changes are not rare. DST started earlier this year in Australia as a one-off for the Commonweath Games. DST ended earlier this year in Syria and Egypt for Ramadan.
This problem has been solved for 20 years by the Olson zone database.
Oracle uses this, and it's possible that the one page from your web search is correct in saying that it's unaffected (though I would be suspicious too without official confirmation).
I still think you're missing the point....
A *technical* solution may have existed for twenty years but that doesn't change the fact that a change of this nature requires users to make a configuration change to their infrastructures (many times over) and they need to know that they need to do it.
In addition, software vendors must make the altered configurations available.
Imagine the world was such that all software used the same table. There would still be a need to distribute the new table to all systems, find a suitable time to install it, test and bring the machines back on line.
It's painful....
My last post was meant to address only the first paragraph in your previous post. I agree with most of your article, though some of the problems you mention such as missed meetings and software problems seem inevitable whenever DST starts or ends. :-)
There will be a cost for implementation, but if everyone used the the same table - and you might be overestimating the problem anyway - I would expect it to be fairly low like more "routine" changes to tax rates or accounting rules rather than Y2k scale. Unfortunately it appears that Sun have made things difficult by ignoring Henry's advice: "the irony of Sun messing up DST".
In any case, it wouldn't be the first time people have come to grief when the clocks went back on a different day...
Love the links. Thanks Ben.
I hadn't realised what a nasty problem this was for users of JVMs.... I dread to think how many of them I have on my machine.
... this year there was a (sadly defunct) proposal to move England to +1.
Happily there's a new one.
Thanks for the link, Ben
Post a Comment