Visual Studio and Daylight Saving Time Change

In 2005, the United States government passed the Energy Policy Act of 2005. This act changes the start and end dates for Daylight Saving Time (DST) as of spring 2007. These changes may impact the way applications run. Microsoft is releasing an update for Windows through Microsoft Update that reflects these changes. For more information, see the Daylight Saving Time Help and Support Center.

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. The standard System.TimeZone class provides a managed wrapper for the underlying Windows Operating System time zone functions.

In addition, developers who use Visual C++ may find their applications affected if they use the CRT time functions, or the TZ environment variable. Fixes for these issues are available through the following KB articles:

• KB932389 - FIX: 2007 daylight savings time update for the TZ environment variable in the Visual C++ Redistributable Package in Visual Studio 2005
• KB932392 - FIX: Visual C++ .NET 2005 C runtime daylight saving time 2007 update for the TZ environment variable
• KB932391 - FIX: Visual C++ .NET 2005 SP1 C runtime daylight saving time 2007 update for the TZ environment variable
• KB932299 - FIX: Visual C++ .NET 2003 C runtime daylight saving time 2007 update for the TZ environment variable problem
• KB932298 - FIX: Visual C++ .NET 2003 SP1 C runtime daylight saving time 2007 update for the TZ environment variable problem
• KB932305 - FIX: Visual C++ .NET 2002 C runtime daylight saving time 2007 update for the TZ environment variable problem
• KB932304 - FIX: Visual C++ .NET 2002 SP1 C runtime daylight saving time 2007 update for the TZ environment variable problem

Most applications that use these affected classes will not need to be modified as this update will ensure that the correct data is provided seamlessly to the application. However, applications that use these classes or the underlying Windows API to perform historical time look-ups will need to be modified. For more information, see the FAQ that follows.

In most cases, developers who have extended the .NET Framework’s time zone support by creating custom time zone classes derived from System.TimeZone, or by direct access to the Win32 API, will not have to update their applications as long as the available updates to the operating system are applied. However, solutions that rely on private time zone data, or that retrieve system time zone information by accessing the registry directly, may need to be updated. Applications that deal with historical time zone data may also need to be updated.

Microsoft advises all developers who make use of time zone data to test their applications against this update to ensure that their applications function correctly.

For more information, see Preparing for daylight saving time changes in 2007 and KB928388: 2007 time zone update for Microsoft Windows operating systems.

Frequently Asked Questions

Q: What dates have changed?

A: DST dates in the United States will start three weeks earlier (2:00 A.M. on the second Sunday in March) and will end one week later (2:00 A.M. on the first Sunday in November).

Q: I just use the DST lookup to get the current correct time, do I need to do anything?

A: 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.

Q: Which .NET Framework classes are affected?

A: Both System.TimeZone and System.DateTime will automatically reflect these rule changes provided the underlying Windows updates are applied. A new .NET Framework class in Visual Studio 2008, TimeZoneInfo, will support serialization and deserialization of time zone data and multiple adjustment rules.

Q: Are any other products affected?

A: The DST changes also affect Visual SourceSafe because it uses the operating system to generate time stamping information. The complete scope and resolutions steps are discussed in KB931804: Visual SourceSafe daylight saving time issues in 2007.

Q: I’m a C++ developer who uses the TZ environment variable, what does this mean to me?

A: For customers who rely on the TZ environment variable for the DST information, they will get outdated DST information for 2007 and beyond (i.e., they will get DST information according to the previous system). See the KB articles listed at the top of this page for fixes to this issue. This issue is also fixed in Visual Studio 2008.

Q: I do historical DST lookups, what does this mean to me?

A: Prior to Windows Vista, Windows offered support for only a single set of adjustment rules. This meant that daylight saving time rules can be applied to any date to generate a historical DST value (regardless if it was accurate). After the DST update, versions of Windows prior to Windows Vista will have DST values that are correct for 2007 onwards but historical DST values may not be.

Windows Vista offers support for multiple time zones, but the actual data in the registry provides for two adjustment rules in the United States. This means that historic time zone information is accurate from 1986 onward (the current adjustment rules, which are replaced by the DST changes, date to 1986), but is inaccurate for dates before 1986.

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.

Q: What is your plan for the future?

A: In Visual Studio 2008, we are building a new class that supports time zones with multiple adjustment rules and user-defined time zones. It retrieves its basic time zone information from the registry, but it supports serialization and deserialization of time zone data, making it possible to develop an historically accurate, time-zone aware application. In addition, this class enables developers to create custom time zones without needing to create custom implementations of this new class. The support for serialization and multiple adjustment rules will enable developers to create accurate, time zone-aware applications that far surpass Windows’ native ability.