Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel behebt ein Problem, bei dem die angezeigte Zeit auf betroffenen Computern nicht mit der aktuellen Ortszeit übereinstimmt, nachdem Sie ein direktes Upgrade auf eine 64-Bit-Version von Windows 7 oder Windows Server 2008 R2 durchgeführt haben.
Ursprüngliche KB-Nummer: 2001086
Problembeschreibung
Stellen Sie sich folgendes Szenario vor:
Sie installieren eine 64-Bit-Version von Windows Vista, Windows 7 oder Windows Server 2008 R2.
Sie legen die Zeitzone auf Israel Standardzeit fest. In Windows Vista wird dies als (GMT+02:00) Jerusalem angezeigt. Unter Windows 7 und Windows Server 2008 R2 wird dies als (UTC+02:00) Jerusalem angezeigt.
Sie führen ein direktes Upgrade auf eine 64-Bit-Version von Windows 7 oder Windows Server 2008 R2 durch.
Erwartetes Verhalten:
Nach dem Upgrade ist die Zeitzoneneinstellung ordnungsgemäß konfiguriert, und features wie "Dynamischer DST" funktionieren weiterhin.
Beobachtetes Verhalten:
Nach dem Upgrade kann die aktuelle Zeitzone nicht von der GetDynamicTimeZoneInformation() -API erkannt werden. Ohne Benutzereingriff darauf zu korrigieren, wird dynamischer DST unterbrochen, und der Computer passt sich nicht an die richtigen Datumsangaben in den kommenden Jahren an. Daher stimmt die angezeigte Uhrzeit auf betroffenen Computern nicht mit der aktuellen Ortszeit überein.
Wenn dieses Problem auftritt, erhalten Benutzer keine Benachrichtigung über den Fehler.
Zusätzliches Windows Server 2008 R2-Problem
Auf Windows Server 2008 R2-Servern können Sie die Zeitzoneneinstellung nicht ändern, und Sie erhalten die folgende Fehlermeldung:
Ihre aktuelle Zeitzone wird nicht erkannt. Wählen Sie eine gültige Zeitzone aus.
Ursache
Die Registrierungseinstellung TimeZoneKeyName ist als 128 WCHAR-REG_SZ Datentyp definiert. Wenn der 128. WCHAR in TimeZoneKeyName kein Null-Terminator ist, fügt der Systemupgradeprozess (Offline.xml) eine Null an die Zeichenfolge an. Dies erhöht die Länge auf 129 WCHARs. Da Windows über einen 128 WHCAR-Puffer verfügt, in dem diese Daten gespeichert werden sollen, lädt das System die geänderte Zeichenfolge nicht aus der Registrierung.
Dieses Problem gilt für Upgrades auf 64-Bit-Windows 7 und Windows Server 2008 R2.
Zusätzliche Ursache für Windows Server 2008 R2
Berechtigungen fehlen auf nicht funktionierenden Servern für den folgenden Registrierungsunterschlüssel:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones und HKLM\System\CurrentControlSet\Control\TimeZoneInformation
Lösung
Starten Sie auf Windows Server 2008 R2-Computern das Element "Datum und Uhrzeit" in Systemsteuerung oder auf der Windows-Taskleiste. Wenn die Meldung im Zeitfenster angibt, dass die Zeitzone nicht erkannt wird, klicken Sie auf "Zeitzone ändern", überprüfen Sie die Zeitzoneneinstellung, und drücken Sie dann "OK". Dadurch werden die richtigen Werte in TimeZoneKeyName wiederhergestellt. Überprüfen Sie auf Windows 7-Clients ihre Zeitzonenauswahl während der Windows-Willkommensseite-Phase des Setups. Dadurch wird die TimeZoneKeyName-Einstellung in der Registrierung wiederhergestellt.
Notiz
- Das Windows-Betriebssystem verwendet UTC-Zeit intern für zeitabhängige Vorgänge. Die angezeigte Zeit, die in der Windows-Taskleiste oder Systemsteuerung Element angezeigt wird, basiert auf UTC-Zeit plus oder minus einem regionalen Zeitversatz, der für Sommerzeitzeitenregeln basierend auf dem Gebietsschema der lokalen Computer zeitzone korrigiert wurde.
- Dieser Fehler wirkt sich nicht auf die von Windows verwendete interne Systemzeit aus. Es kann dazu führen, dass die angezeigte Zeit falsch angezeigt wird.
- Wenn Sie die Zeiteinstellung im Element "Datum und Uhrzeit " korrigieren, überprüfen Sie zunächst, ob die richtige Zeitzone konfiguriert wurde. Führen Sie dies aus, bevor Sie Datums- oder Stundenänderungen vornehmen, damit Sie nicht versehentlich eine falsche Systemzeit konfigurieren.
Weitere Informationen
Dynamischer DST
In einigen Ländern/Regionen unterscheiden sich die DST-Datumsangaben von Jahr zu Jahr und können nicht durch eine einzelne Regel definiert werden. Daher enthält Windows das Dynamische DST-Feature, das regeln pro Jahr in der Registrierung speichert. Wenn sich das Jahr ändert, werden die aktuellen Zeitzoneninformationen mithilfe der richtigen DST-Informationen für dieses Jahr aktualisiert.
Dynamischer DST hängt vom folgenden Registrierungswert ab, der auf den Namen des Zeitzonenschlüssels festgelegt wird, in dem sich die dynamischen DST-Daten befinden (z. B. "Israel Standardzeit"):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName
Nur Zeitzonen mit unterschiedlichen Regeln für unterschiedliche Jahre (Dynamic DST) sind betroffen. Dies liegt daran, dass der Registrierungswert, der angibt, wo diese regeln pro Jahr gespeichert werden, beschädigt ist. Wenn dieser Wert fehlt, werden die Zeitzoneninformationsdaten nicht im nächsten Jahr änderungszeitraum aktualisiert. Dies bewirkt, dass die DST-Regeln des Vorjahres zum Berechnen der Ortszeit verwendet werden. Unmittelbar nach dem Upgrade der Systemversion ist die Anzeigezeit von diesem Problem nicht betroffen. Sie erhalten eine Benachrichtigung über eine nicht erkannte Zeitzone, wenn Sie auf die Taskleistenuhr klicken oder das Datums- und Uhrzeitelement in der Systemsteuerung öffnen.
Wenn die Zeitzone nicht korrigiert wird, können zukünftige Übergänge zu oder von DST zur falschen Zeit auftreten. Dies würde zu einer falschen Zeit auf dem System oder zu falschen Konvertierungen zwischen System und Ortszeit führen.
Alle Zeitzonen sind potenziell betroffen, aber der Haupteffekt liegt auf Betriebssysteminstallationen, die für die Verwendung von Zonen konfiguriert sind, die dynamische DST-Daten enthalten. Die Zeitzonen, die dynamische DST unterstützen, sind wie folgt:
Alaska Normalzeit
Arabische Normalzeit
Argentinien Normalzeit
Atlantic Normalzeit
Ostaustralische Normalzeit
Cen. Ostaustralische Normalzeit
Zentralbrasilianische Normalzeit
Central Normalzeit
E. Östl. Südamerika Normalzeit
Eastern Normalzeit
Ägypten Normalzeit
Grönland Normalzeit
Iran Normalzeit
Israel Normalzeit
Mauritius Normalzeit
Montevideo Normalzeit
Marokko Normalzeit
Mountain Normalzeit
Neuseeland Normalzeit
Neufundland Normalzeit
Chilenische Normalzeit
Pacific Normalzeit
Pakistan Normalzeit
Paraguay Normalzeit
Tasmanien Normalzeit
Venezuela Normalzeit
W. Ostaustralische Normalzeit
Der Grund dafür, dass die Auswirkungen in diesem Fall größer sind, besteht darin, dass die DST-Daten für die Zeitzone möglicherweise nicht aktualisiert werden, um die Regeln widerzuspiegeln, die für das jeweilige Jahr in Kraft sein sollten. Dies kann dazu führen, dass ein Übergang zu oder von DST zur falschen Zeit in der angegebenen Zeitzone erfolgt. Dies ist kein Problem, wenn dynamischer DST nicht in der Zeitzone vorhanden ist. Die beschädigten Registrierungsdaten führen jedoch dazu, dass ein Aufruf von GetDynamicTimeZoneInformation() fehlschlägt, unabhängig davon, ob die Zeitzone dynamische DST unterstützt.