The issue can be understood by a comparison between two different operating systems. Take Windows Vista on one side and Windows 7 or Windows Server 2008 R2 on the other side.
You install a 64 bit copy of both Windows Vista and on Windows 7 or Windows Server 2008 R2. After the installation, you set the time on it. Let’s say Israel Standard Time is set. When you see the display of time on Windows Vista, it would appear as (GMT+02:00) Jerusalem and when you observe the time on Windows 7 or Windows Server 2008 R2, it would display (UTC+02:00) Jerusalem.
On a 64 bit RTM version of Windows 7 or Windows Server 2008 R2, when you do an in place upgrade , you would expect that the time zone set by you has the right configuration and its features like Dynamic DST would be working properly with no issues. But this actually does not happen. The actual impact is that after do the up gradation, the GetDynamic Time Zone Information () API does not identify the time zone which is currently set there. It would break the Dynamic DST and your system will not be able to match the Dynamic DST with the actual current dates for the next years to come which will further mean that the time which is reflected on this affected computer will not be the same actual current local time. It will not match. The worse thing here is that once the up gradation is performed, the user will not even get the time to correct it or do something on it. It will automatically happen displaying the improper time on the screen.
Also, the person using the system will not get any pop up error or any information about this after this problem.
Root cause of the issue:
There is a reason for the occurrence of this type of issue. The term Time Zone Key Name is of 128 WCHAR REG_SZ data type. The 128th WCHAR in the Time Zone Key Name should be a null terminator. But if it is not a null terminator, then when you would start the upgrade on Windows 7 or Windows Server 2008 R2, then that process will add that null to the string result of which will be increase in the length of WCHAR. Its length will be increased to 129 WCHARs. Not in all operating systems but in Windows 7 or Windows Server 2008 R2, they have the data storage capacity of only 128 WCHAR due to which it is not able to load the appended and changed string from the registry.
Solution to this issue:
There is no need to worry for it as there is a solution to overcome this problem.
If the Operating System is Windows Server 2008 R2, then you should on the control panel, launch the option “Date and Time”. If you see the message in the clock fly away that it is not able to identify the time zone, select the option” Change Time Zone”. After the proceedings, when you get the correct time, select that and then press “OK”. This action will update the precise values to the setting of Time Zone Registry.
However, if the Operating System is Windows 7, then the users should make sure the time zone at the time of OOBE phase of the set up process only. This action will store back the setting of TimeZoneKeyName in the registry. This way the users of Windows 7 or Windows Server 2008 R2 will not face any issue while performing an in place upgrade of 64 bit version on these operating systems.