Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
Incorrect time displayed on 64-bit versions of Windows 7 or Windows Server 2008 R2 after in-place upgrade
Article ID: 2001086 - View products that this article applies to.
Assume the following scenario:
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.
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.
This bug will not affect the internal system time used by Windows. It can cause the displayed time to appear incorrect.
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.
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.
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.
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.