The Daylight Savings Time switch earlier this year did more than throw off Outlook calendars. The .NET Framework needed a bit of a tweak to accommodate the change. This tip looks at what has changed and what it means in the future.
In 2005, the U.S. Congress passed the Energy Policy Act of 2005. Among its many articles, it included a change to the start and end dates for Daylight Savings Time starting this spring. For those of you who didn't notice, daylight savings took effect three weeks earlier and will end one week later than normal this year.
I myself wondered why Microsoft included a daylight savings time patch among its priority updates until I learned that the rules for Daylight Savings Time were changing as a result of this legislation. (Until then, I steadfastly refused to apply that patch, as I'm sure many others also did who weren't aware that Congress had changed the rules of the daylight savings game.) As the name of governing legislation should suggest, the idea is to save energy by pushing daylight forward earlier and backward later, so as to make the most of the sun's light when it's available to us in North America.
What many may not stop to notice is that the .NET Framework has to bend to accommodate this legislative innovation, too, which means that everybody should be aware that the rules of the timing game have changed, and that the date and time capabilities of Windows must also change to follow suit.
As it happens, .NET gets its time zone and time information from the OS, so changing Windows is necessary to make the .NET Framework get things right. In that vein, the System.TimeZone and System.DateTime classes automatically will only reflect these rule changes, if the underlying (and necessary) Windows updates are applied to the operating systems on which the framework runs.
Orcas (the beta version of the next and upcoming version of Visual Studio) addresses this dependency by including a TimeZone2 .NET Framework class that supports serialization and deserialization of time zone data. This permits explicit application of one or more adjustment rules. So in the future, this year's problem shouldn't plague developers, who must currently rely on end-user application of patches so that notions of time are correct in the machines on which their code runs.
This also means that C++ developers who use the TZ (timezone) variable in their applications will get outdated daylight savings time information in their applications in 2007 and the future thereafter (in that the Daylight Savings Time information that this variable returns conforms to the old set of rules rather than the new ones). Microsoft is working on a fix to this problem, and will post information when it becomes available on the Visual Studio Support pages.
In the long term, upgrading to Orcas will address this problem because it builds in sensitivity to the rules that apply to calculations that require sensitivity to daylight savings time, and is even smart enough to apply the right rules to the time frames to which they apply. Those who often stop to consider that "their time is not their own" may regard this old aphorism a bit more ruefully in the future, as they have to change their applications to match the new rules for when time springs forward and falls back!
Ed Tittel is a writer and trainer whose interests include XML and development topics, along with IT Certification and information security. E-mail etittel@techtarget.com with comments, questions, or suggested topics or tools to review. Cool tools rule!
