In these cases, we bemoan the abstract quality that is time. This time next week, however, there's a chance we may actually curse time itself. That's because numerous Daylight Savings Time, or DST, changes are in order.
The most notable is occurring in the United States, where March 11 is the new start date for DST. The federal government decided that three more weeks of evening daylight in the spring, and an additional week in the fall, would help lower energy costs and raise spirits. Canada has adopted these same DST changes, but Mexico has not.
In addition, new DST dates have been established in Brazil, Egypt and Israel, and time zone modifications are in order for Sri Lanka and Uruguay.
This switch does present some implications for IT. According to a letter that Microsoft sent to its customers, "Developers who use the .NET Framework may find their applications affected if the application uses the time zone information for historical purposes or if they have derived custom classes from System.TimeZone to provide custom time zone information." (Many bloggers, including Aaron Fischer, have posted the full text of this letter.)
Some prognosticators are comparing the DST fix to the Y2K scare -- not so much in terms of its scale as, it is hoped, in terms of its potential for fizzling out.
To that end, Microsoft has compiled a variety of resources detailing what will have to change and how those changes should be implemented. Here are a few that should be helpful to you:
Enterprises using Windows Vista and Office 2007 have nothing to worry about -- the new DST rules were programmed in when Microsoft was writing that software.
Finally, Microsoft seeks to alleviate situations like this by introducing a new class into Visual Studio "Orcas," due at the end of 2007 or the beginning of 2008. This class, according to the company, will support time zones with multiple adjustment rules, user-defined time zones and the creation of custom time zones without the need for custom implementations.