Onjuiste tijd weergegeven in 64-bits versies van Windows 7 of Windows Server 2008 R2 na in-place upgrade

  • Artikel

In dit artikel wordt een probleem opgelost waarbij de weergegeven tijd op de betreffende computers niet overeenkomt met de huidige lokale tijd nadat u een in-place upgrade hebt uitgevoerd naar een 64-bits versie van Windows 7 of Windows Server 2008 R2.

Van toepassing op: Windows 10 - alle edities, Windows Server 2012 R2
Origineel KB-nummer: 2001086

Symptomen

Neem het volgende scenario:

  • U installeert een 64-bits versie van Windows Vista, Windows 7 of Windows Server 2008 R2.

  • U stelt de tijdzone in op Israël (standaardtijd). In Windows Vista wordt dit weergegeven als (GMT+02:00) Jeruzalem. In Windows 7 en Windows Server 2008 R2 wordt dit weergegeven als (UTC+02:00) Jeruzalem.

  • U voert een in-place upgrade uit naar een 64-bits versie van Windows 7 of Windows Server 2008 R2.

    Verwacht gedrag:

    Na de upgrade is de tijdzone-instelling correct geconfigureerd en blijven functies zoals Dynamische DST werken.

    Waargenomen gedrag:

    Na de upgrade kan de huidige tijdzone niet worden herkend door de GetDynamicTimeZoneInformation() API. Zonder tussenkomst van de gebruiker om dit te corrigeren, wordt dynamische DST verbroken en wordt de computer niet aangepast voor de DST op de juiste datums in de komende jaren. Daarom komt de weergegeven tijd op de betreffende computers niet overeen met de huidige lokale tijd.

    Wanneer dit probleem zich voordoet, ontvangen gebruikers geen melding over de fout.

Aanvullend probleem met Windows Server 2008 R2

Op Windows Server 2008 R2-servers kunt u de tijdzone-instelling niet wijzigen en u ontvangt het volgende foutbericht:

Uw huidige tijdzone wordt niet herkend. Selecteer een geldige tijdzone.

Oorzaak

De registerinstelling TimeZoneKeyName is gedefinieerd als een 128 WCHAR REG_SZ gegevenstype. Als de 128e WCHAR in TimeZoneKeyName geen null-afsluiter is, voegt het systeemupgradeproces (Offline.xml) een null toe aan de tekenreeks. Hierdoor wordt de lengte verhoogd tot 129 WCHAR's. Omdat Windows een 128 WHCAR-buffer heeft waarin deze gegevens kunnen worden opgeslagen, laadt het systeem de gewijzigde tekenreeks niet uit het register.

Dit probleem geldt voor upgrades naar 64-bits Windows 7 en Windows Server 2008 R2.

Extra Windows Server 2008 R2-oorzaak

Er ontbreken machtigingen op niet-werkende servers voor de volgende registersubsleutel:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones en HKLM\System\CurrentControlSet\Control\TimeZoneInformation

Oplossing

Start op Windows Server 2008 R2-computers het item Datum en tijd in Configuratiescherm of op de Windows-taakbalk. Als het bericht in het klokvenster aangeeft dat de tijdzone niet wordt herkend, klikt u op Tijdzone wijzigen, controleert u de instelling van de tijdzone en drukt u op OK. Hiermee worden de juiste waarden hersteld naar TimeZoneKeyName. Controleer op Windows 7-clients uw tijdzoneselectie tijdens de OOBE-fase van setup. Hiermee wordt de instelling TimeZoneKeyName in het register hersteld.

Opmerking

  • Het Windows-besturingssysteem gebruikt intern UTC-tijd voor tijdafhankelijke bewerkingen. De weergegeven tijd die wordt weergegeven op de Windows-taakbalk of Configuratiescherm item is gebaseerd op UTC-tijd plus of min een regionale tijd offset gecorrigeerd voor zomertijdregels op basis van de landinstellingen van de lokale computers.
  • Deze fout heeft geen invloed op de interne systeemtijd die door Windows wordt gebruikt. Dit kan ertoe leiden dat de weergegeven tijd onjuist wordt weergegeven.
  • Wanneer u de tijdinstelling in het item Datum en Tijd corrigeert, controleert u eerst of de juiste tijdzone is geconfigureerd. Doe dit voordat u datum- of uurwijzigingen aanbrengt, zodat u niet onbedoeld een onjuiste systeemtijd configureert.

Meer informatie

Dynamische DST

In sommige landen/regio's verschillen de vervaldatums van jaar tot jaar en kunnen ze niet worden gedefinieerd door één regel. Daarom bevat Windows de functie Dynamische DST waarmee regels per jaar in het register worden opgeslagen. Wanneer het jaar verandert, wordt de huidige tijdzone-informatie vernieuwd met behulp van de juiste DST-informatie voor dat jaar.

Dynamische DST is afhankelijk van de volgende registerwaarde die wordt ingesteld op de naam van de tijdzonesleutel waar de dynamische DST-gegevens zich bevinden (bijvoorbeeld 'Israel Standard Time'):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName

Alleen tijdzones met verschillende regels voor verschillende jaren (dynamische DST) worden beïnvloed. Dit komt doordat de registerwaarde die aangeeft waar deze regels per jaar worden opgeslagen, beschadigd is. Als deze waarde ontbreekt, worden de informatiegegevens van de tijdzone niet vernieuwd tijdens de overgangsperiode van het volgende jaar. Dit zorgt ervoor dat de DST-regels van het vorige jaar worden gebruikt om de lokale tijd te berekenen. Direct na de upgrade van de systeemversie wordt de weergavetijd niet beïnvloed door dit probleem. U krijgt een melding van een niet-herkende tijdzone als u op de taakbalkklok klikt of het item Datum en tijd opent in de Configuratiescherm.

Als de tijdzone niet wordt gecorrigeerd, kunnen toekomstige overgangen van of naar de geplande periode op het verkeerde moment plaatsvinden. Dit zou ertoe leiden dat een onjuiste tijd op het systeem of onjuiste conversies tussen het systeem en de lokale tijd onjuist zijn.

Alle tijdzones worden mogelijk beïnvloed, maar het belangrijkste effect is op installaties van besturingssystemen die zijn geconfigureerd voor het gebruik van zones die dynamische DST-gegevens bevatten. De tijdzones die dynamische DST ondersteunen, zijn als volgt:

Alaska (standaardtijd)
Arabisch (standaardtijd)
Argentinië (standaardtijd)
Atlantic (standaardtijd)
AUS Eastern (standaardtijd)
Cen. Australië (standaardtijd)
Centraal Braziliaans (standaardtijd)
Central (standaardtijd)
E. Zuid-Amerika (standaardtijd)
Eastern (standaardtijd)
Egypte (standaardtijd)
Groenland (standaardtijd)
Iran (standaardtijd)
Israël (standaardtijd)
Mauritius (standaardtijd)
Montevideo (standaardtijd)
Marokko (standaardtijd)
Mountain (standaardtijd)
Nieuw-Zeeland (standaardtijd)
Newfoundland (standaardtijd)
Pacific SA (standaardtijd)
Pacific (standaardtijd)
Pakistan (standaardtijd)
Paraguay (standaardtijd)
Tasmanië (standaardtijd)
Venezuela (standaardtijd)
W. Australië (standaardtijd)

De reden dat de impact in dit geval groter is, is dat de gegevens over de einddatum voor de tijdzone mogelijk niet worden bijgewerkt om de regels weer te geven die voor het opgegeven jaar van kracht moeten zijn. Dit kan ertoe leiden dat een overgang naar of van de DST plaatsvindt op het onjuiste tijdstip in de opgegeven tijdzone. Dit is geen probleem als dynamische DST niet aanwezig is in de tijdzone. De beschadigde registergegevens laten echter elke aanroep van GetDynamicTimeZoneInformation() mislukken, ongeacht of de tijdzone dynamische zomertijd ondersteunt.