Incorrect time displayed on 64-bit versions of Windows 7 or Windows Server 2008 R2 after in-place upgrade

Assume the following scenario:

1. You install a 64-bit copy of Windows Vista, or a 64-bit version of Windows 7 or Windows Server 2008 R2.
   
   
2. You set the time zone to Israel Standard Time. In Windows Vista this will be displayed as (GMT+02:00) Jerusalem. On Windows 7 and Windows Server 2008 R2 this will be displayed as (UTC+02:00) Jerusalem.
   
   
3. You perform an in-place upgrade to a 64-bit RTM version of Windows 7 or Windows Server 2008 R2.

Expected Behavior:

After upgrading, the time zone setting is correctly configured and features such as Dynamic DST continue to work.

Observed Behavior:

After upgrading, the current time zone cannot be recognized by the GetDynamicTimeZoneInformation() API. Without user intervention to correct this, Dynamic DST will be broken and the computer will not adjust for DST on the correct dates in upcoming years, meaning the displayed time on affected machines will not match the current local time.

Users will not get a notification or pop-up error as a result of this problem.

Back to the top | Give Feedback

The TimeZoneKeyName is defined as a 128 WCHAR REG_SZ data type. If the 128th WCHAR in TimeZoneKeyName is not a null terminator, then the OS upgrade process (offline.xml) will append a null to the string, increasing its length to 129 WCHARs. As Windows only has a 128 WHCAR buffer to store this data, it fails to load the modified string from the registry.

This bug applies to upgrades to 64-bit Windows 7 and Windows Server 2008 R2 operating systems.

Back to the top | Give Feedback

On Windows Server 2008 R2 computers, launch the Date and Time applet in Control Panel or the Windows task bar. If the message in the clock fly-away indicates that the time zone is unrecognized, click on Change time zone... Confirm the time zone and hit OK. This will restore correct values to the TimeZoneKeyName registry setting.

On Windows 7 clients, confirm your time zone selection during the OOBE phase of setup which restores the TimeZoneKeyName setting in the registry.

Note:

The Windows operating system uses UTC time internally for time-dependent operations. The displayed time that appears in the Windows task bar or control panel applet is derived from UTC time plus or minus a regional time offset corrected for daylight saving times rules based on the local computers time zone locale.

This bug will not affect the internal system time used by Windows. It can cause the displayed time to appear incorrect.

When correcting time in the date and time applet, first verify that the the correct time zone has been configured before making any date or hour changes so that you do not unintentionally configure a bad system time.

Back to the top | Give Feedback

Dynamic DST

Some countries have different DST dates each year that cannot be defined by a single rule. As a result Windows has a feature called Dynamic DST where per-year rules are stored in the registry. When the year changes the current time zone information is refreshed with the correct DST information for that year.

Dynamic DST relies on the following registry value being set to the name of the time zone key where the Dynamic DST data resides (e.g. “Israel Standard Time” in the case above):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName

Only time zones that have different rules for different years (a.k.a. Dynamic DST) are affected (as the registry value which indicates where these per-year rules are stored is corrupted).

If this value is missing then the time zone information data will not be refreshed at the next year changeover period, resulting in the previous year’s DST rules being used to calculate local time.

Immediately following OS version upgrade, display time is not be affected by this issue. You will get a notification of an unrecognized time zone if you click on the taskbar clock or open the control panel applet.

If the time zone is not corrected, then potentially future transitions to or from DST could occur at the wrong time, resulting in time being incorrect on the system, or conversions between system and local time being incorrect.

All time zones are potentially affected, but the main impact is on operating system installs configured to use zones that contain Dynamic DST data. The time zones that support Dynamic DST are:

Alaskan Standard Time
Arabic Standard Time
Argentina Standard Time
Atlantic Standard Time
AUS Eastern Standard Time
Cen. Australia Standard Time
Central Brazilian Standard Time
Central Standard Time
E. South America Standard Time
Eastern Standard Time
Egypt Standard Time
Greenland Standard Time
Iran Standard Time
Israel Standard Time
Mauritius Standard Time
Montevideo Standard Time
Morocco Standard Time
Mountain Standard Time
New Zealand Standard Time
Newfoundland Standard Time
Pacific SA Standard Time
Pacific Standard Time
Pakistan Standard Time
Paraguay Standard Time
Tasmania Standard Time
Venezuela Standard Time
W. Australia Standard Time

The reason that the impact here is greater is that the DST data for the time zone may not be updated to reflect the rules that should be in force for the given year. This may lead to transition to or from DST occurring at the incorrect time in the given time zone. This is not an issue if Dynamic DST is not present in the time zone. However, the corrupt registry data results in any call to GetDynamicTimeZoneInformation() failing, regardless of whether the time zone supports dynamic DST or not.

Back to the top | Give Feedback