Originally posted on: http://geekswithblogs.net/meshel/archive/2006/06/11/81456.aspx
I've recently been assigned the task of preparing our software to the DST (Daylight Saving Time) that is going to be implemented in the
Our system (http://www.interwise.com) deals with event scheduling, so obviously such a change matters to us, and we have to at least asses what will happen when this change comes into effect.
As you probably already know, DST is a method in which during “summertime” the clock is moved ahead. This is done to “catch-up” with the sun, so that say 7:00 AM will always be in daylight. The main advantage of this system is that there are major energy savings, and that workers do not have to leave there house when it is still dark (biological clock is synchronized). This is good!
As you can guess there is also some bad news... like many other systems out there, everyone implements differently in this case each country (and sometimes each county/region) decides for itself, as with time-zone. And no one does it the same way. As far as I can tell the winners in the bizarre competitions (and it's almost tied) are
This situation causes headaches for developers and vendors who have a reliance on this data (almost all software relies on TIME, although it is not always critical). I will not detail all the problems but you can guess that no software deals well with situations that the developer could not predict / pre-plan for. This situation practically forces patches being released. And currently it is causing me headache L
The funny thing for us (in us I mean vendors who are not Microsoft) is that Microsoft and such vendors (Oracle, SAP), are not releasing any information about what they are planning to do about DST changes in the USA in 2007, so we are kind of left in the dark. Obviously any change we make or not make is based on the platform we are using, and if we don’t know how the platform will deal with the situation – we can not plan ahead. So what is going on? Will anyone from MS please step up?
Some links that shed light on previous solutions for DST on Microsoft products:
http://support.microsoft.com/kb/832869 (side effect on older data, search behaves differently than expected)
Update (21/06/2006): I have been informed that the Microsoft solution will be the standard one (a patch that updates the time zone information in the registry), also Sun has already issued an OS patch for the issue here: http://blogs.sun.com/roller/page/telecom?entry=new_dates_for_daylight_savings and here:http://sunsolve.sun.com/search/document.do?assetkey=1-26-102178-1