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 USA beginning March 2007. (link that explains the exact changes: http://www.energy.ca.gov/daylightsaving.html)
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 Israel and Brazil where the system is completely abused. In Israel a law was recently passed that declares that DST begin and end time is controlled by TWO different calendars, the beginning is based on the Gregorian calendar and the ending is based on the Jewish calendar (until this law was passed every year saw a different definition of DST based on a government minister good only for that year and depending on his sole judgment)... In Brazil the system appears sane until you understand that it depends on a local holiday that doesn't have a stable date (and apparently relies on a different calendar as well). There are more oddities around the world - Australia with the Olympic Games specific change, USA with the state of Indiana in which different counties had there own definitions on both time-zone and DST.
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