One of the most talked about topics in the industry right now is how the U.S. government's changes to Daylight Saving Time (DST) will affect IT resources. Most of the attention is focused on operating systems, but application developers are raising a number of questions as well. Let's take a closer look at the DST changes, explore how they may impact your applications, and outline what help is available.
The Energy Policy Act of 2005, which was signed by George Bush in August 2005, extended DST in the United States. Beginning this year, DST will start three weeks earlier (on March 11) and end one week later (on November 4), resulting in a new DST period that is four weeks longer than previously observed.
When your time zone settings are incorrect, your system clock may be off by one hour, and certain applications running on your computer may not display the correct time. Patches are available for most systems including Microsoft-based operating systems and products. Microsoft has not, however, provided a lot of information regarding how the change may affect .NET-based products.
Dealing with DST
For .NET developers, issues arise in applications running in areas that recognize DST. (DST is not observed in Hawaii, American Samoa, Guam, Puerto Rico, the Virgin Islands, and by most of Arizona.) When using DST, there is one hour each fall and spring where issues arise with respect to time. During the spring on the night that the clock time shifts from standard to DST, the time moves ahead one hour. Conversely, in the fall, the local time clock is rolled back an hour.
You may notice problems occur on the days when the time changes. Most notably, you can encounter conditions where the day appears to be 23 or 25 hours long. In these situations, problems may arise when you're working with time values that span the time change window, and the code will have to adjust the value accordingly.
Most problems will arise when date-time values are accepted and stored via user input. Microsoft advises developers to determine when and if certain values are not valid when using the DateTime.Parse method to calculate values based on user input. This is true on the days where time is rolled backward an hour (on 23-hour days) and when values have two meanings (on 25-hour days when time is moved forward). To do this, you need to know the dates involved and look for these hours. It may be useful to parse and redisplay the interpreted date information as the user exits the fields used to enter dates. As a rule, try to get your users not to specify DST in their input.
You can avoid most of these issues by converting input values to universal time. Currently, the .NET Framework does not provide a way to parse a string that represents a user's view of time and have it accurately assigned a universal time value. The reason is that people who experience DST don't live in places where the time zone is Greenwich Mean Time.
In instances where time ambiguities occur, you can use the TimeZone object to determine whether a time falls in DST using the following method:
Or, you can utilize the IsDaylightSavingTime property of the DateTime object, as the following line demonstrates:
How the DST changes may adversely affect apps
.NET applications utilize the date-time values of the underlying operating system, so a patch to the operating system means code will have the correct value, but, as demonstrated in the previous section, issues can still arise. According to Microsoft, .NET developers may find their applications adversely affected by the DST change if the application uses the time zone information for historical purposes, or if they have derived custom classes from the System.TimeZone class to provide custom time zone information.
Microsoft states that you will not need to modify your applications because the time zone support in the .NET Framework relies on time zone data provided by the operating system. Time and time zone aware features of the .NET Framework, such as the System.TimeZone class, will automatically reflect these rule changes provided updates are applied to the operating system.
To retrieve accurate historical DST values, you must create your own implementation that understands the adjustments required and can manipulate the underlying Windows date and time information. As the previous section describes, you'll need to make the code check values and adjust if necessary. You'll need to treat DST-based values before March 11, 2007 differently than values on or after March 11, 2007 going forward.
Check out these DST change-related Microsoft resources for developers:
- Visual SourceSafe 2005 may run into problems, but Visual SourceSafe 6.0d appears okay. This document provides more information.
- The current version of Visual Studio shouldn't be a problem, but a future Visual Studio release will provide a new class that supports time zones with multiple adjustment rules and user-defined time zones.
- Learn more about issues with SQL Server Notification Services here.
The Y2K crisis provided plenty of hysteria and doomsday predictions for the various computer systems around the world. While the upcoming DST change is not as big an issue, it can cause problems. For this reason, all patches and updates should be installed and tested, and you should evaluate applications where historical date-time values are stored and utilized.
Miss a column?
Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.
Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.