Behandeln von Datums- und Uhrzeitangaben, die die Sommerzeit einschließen

In diesem Artikel wird beschrieben, wie Datums- und Uhrzeitangaben behandelt werden, die die Sommerzeit (DST) und die Auswirkungen von Änderungen der Sommerzeit 2007 auf bestimmte Produkte und Technologien umfassen.

              Originalversion des Produkts: Windows
Ursprüngliche KB-Nummer: 932955

Zusammenfassung

Entwickler, die Anwendungen schreiben, die Datums- und Uhrzeitdaten verarbeiten, können eine oder mehrere Technologien verwenden, die Datums- und Uhrzeitbearbeitung durchführen. Insbesondere können bestimmte Basisbetriebssystem-APIs, die C-Runtime (CRT) und die Microsoft .NET Framework Datums- und Uhrzeitangaben konvertieren oder anderweitig bearbeiten. In diesem Artikel werden einige der allgemeinen Konzepte beschrieben, die für die Verarbeitung von Datums- und Uhrzeitangaben gelten.

Zeitspeicherung und -bearbeitung

Zeitstempel sind Werte, die eine Kombination aus Datum und Uhrzeit angeben. Anwendungen, die Zeitstempel verarbeiten müssen, speichern diese Zeitstempel in der Regel in koordinierter Weltzeit (UTC). Der Vorteil von UTC besteht darin, dass UTC universell ist. UTC unterliegt weder lokalen Zeitzonen noch der DST. UTC ist jedoch für die meisten Benutzer nicht benutzerfreundlich oder relevant. Obwohl UTC die offensichtliche Wahl für den Speicher ist, ist dies keine gute Wahl für die Anzeige. Daher konvertieren die meisten Anwendungen UTC-Zeit in Ortszeit, bevor sie dem Benutzer den Zeitstempel anzeigen. Windows Explorer wendet beispielsweise die Zeitzone und die DST-Einstellung auf den UTC-Zeitstempel an, bevor Datums- und Uhrzeitangaben für Dateien in einem NTFS-Verzeichnis (New Technology File System) angezeigt werden.

Die Konvertierung von UTC-Zeit in Ortszeit kann als Anwendung von zwei Offsets betrachtet werden. Die erste ist der Zeitzonenoffset, und der zweite ist der DST-Offset. Daher ist die Ortszeit praktisch UTC-Zeit plus ein Zeitzonenoffset sowie ein beliebiger anwendbarer DST-Offset. Der Zeitzonenoffset ist relativ einfach. Der Computer ist für eine bestimmte Zeitzone konfiguriert, und diese Zeitzone weist einen Offset von UTC auf. Das Bestimmen, ob ein DST-Offset angewendet werden soll, ist viel komplexer. Diese Aktivität basiert auf vielen komplexen und dynamischen Regeln.

Diese komplexen DST-Regeln wurden kürzlich mit DST 2007 geändert. Ab 2007 hat die USA neue Anfangs- und Endtermine für die Sommerzeit festgelegt. Darüber hinaus ist es üblich, dass andere Länder/Regionen und Regierungen die Start- und Endtermine für die Sommerzeit in Zeitzonen, die unter ihrer Kontrolle stehen, routinemäßig ändern. Im folgenden Abschnitt werden die Auswirkungen der DST 2007-Änderung auf entwicklerbezogene Produkte beschrieben.

Weitere Informationen zur Sommerzeit 2007 finden Sie unter Hilfe und Support zur Sommerzeit.

DST 2007-Effekte unter Windows

Auf Windows Update und auf Microsoft Update sind Updates verfügbar, mit denen Windows die Änderungen für die Laufzeit 2007 und für die folgenden Jahre ordnungsgemäß anwenden kann. Nachdem diese Updates angewendet wurden, berechnet Windows die aktuellen Offsets von UTC-Zeit zu Ortszeit ordnungsgemäß, wenn der Computer die DST durchläuft. Die Offsets enthalten die Offsets für die Basis-APIs und für die zeitbezogenen Netzwerk-APIs.

Weitere Informationen finden Sie unter Kumulatives Zeitzonenupdate für Windows-Betriebssysteme vom Dezember 2007.

Auswirkungen von DST 2007 auf C-Runtime (CRT)

Die CRT führt auch Datums- und Uhrzeitübersetzungen durch. Daher muss auch die CRT aktualisiert werden, um die neuen Regeln für die Sommerzeit 2007 einzuschließen. Die CRT führt nur dann eine eigene Zeitbehandlung durch, wenn die TZ-Umgebungsvariable festgelegt ist oder wenn ein zugrunde liegender Api-Zeitaufruf des Betriebssystems fehlschlägt. Updates sind für die CRTs verfügbar, die in jeder Version von Visual Studio enthalten sind, sowie für die CRTs, die in Windows enthalten sind. Diese Updates ermöglichen es der CRT, DST-Konvertierungen in USA Zeitzonen weiterhin ordnungsgemäß zu verarbeiten.

Auswirkungen der DST 2007 auf die .NET Framework

Die .NET Framework basiert auf den zugrunde liegenden Betriebssystemaufrufen. Daher spiegelt das Verhalten des .NET Framework den Zustand des zugrunde liegenden Betriebssystems wider. Es ist kein separates Update erforderlich.

DST 2007-Effekte für Visual Studio .NET-IDEs

Die integrierten Entwicklungsumgebungen (IDEs) von Visual Studio .NET umfassen die Versionen 2002, 2003 und 2005 von Visual C++, Visual C# und Visual Basic. Diese Produkte sind nur betroffen, weil sie die CRT enthalten. Es ist kein IDE-spezifisches Update erforderlich.

DST 2007-Effekte auf Visual Studio 2005 Team Foundation Server

Visual Studio 2005 Team Foundation Server basiert auf dem zugrunde liegenden Betriebssystem für Datums- und Uhrzeitkonvertierungen. Daher weist Visual Studio 2005 Team Foundation Server das gleiche Verhalten wie das Betriebssystem auf. Visual Studio 2005 Team Foundation Server basiert auch auf SQL Server, SQL Server Reporting Services und Windows SharePoint Services. Computer sollten mit den relevanten Updates für das Betriebssystem, für SQL Server und für Windows SharePoint Services aktualisiert werden. Alle relevanten Updates sollten gleichzeitig auf alle betroffenen Computer angewendet werden. Es ist kein separates Visual Studio 2005 Team Foundation Server-Update erforderlich.

DST 2007-Effekte in Visual Studio 2005 Team System

Visual Studio 2005 Team System ist über das Betriebssystem, über Visual Studio 2005 Team Foundation Server und die CRT betroffen. Es ist kein separates Visual Studio 2005 Team System-Update erforderlich.

DST 2007-Effekte auf Visual Basic 6.0-Runtime

Die Visual Basic 6.0-Runtime ist nicht betroffen.

DST 2007-Effekte in Visual C++ 6.0

Visual C++ 6.0 wird nicht mehr unterstützt. Weitere Informationen finden Sie unter Microsoft Lifecycle-Richtlinien.

DST 2007-Effekte im Windows SDK für Windows Vista

Dieses Software Development Kit (SDK) enthält eine Version der CRT, die von den DST 2007-Änderungen betroffen ist. Im Rahmen der Installation dieses SDK können Sie visual Studio 2005 CRT auf Computern installieren, auf denen diese Version der CRT noch nicht installiert ist. Wenn bereits eine neuere Version der CRT installiert ist, überschreibt die SDK-Installation diese neuere Version nicht. Wenn das SDK deinstalliert wird, bleibt die neueste Version von CRT auf dem Computer. Sie können das Visual Studio 2005 CRT-Update entweder vor oder nach der Installation des SDK installieren.

Das Windows SDK für Windows Vista installiert auch eine Reihe von Mergemodulen (MSM-Dateien) für die Visual Studio 2005 CRT für die Neuverteilung der CRT als Teil benutzerdefinierter C++-Anwendungen. Eine Anwendung, die die verteilbare CRT im Installationsordner der Anwendung bereitstellt, muss die aktualisierte CRT aus dem Visual Studio 2005 CRT-Update anstelle der CRT-MSM-Dateien aus dem Windows SDK für Windows Vista bereitstellen. Eine Anwendung, die das verteilbare Visual Studio 2005 CRT-Update im Windows-Installationsordner bereitstellt, muss das verteilbare CRT-Update von Visual Studio 2005 auf diese Computer anwenden.

Auswirkungen von DST 2007 auf das Plattform-SDK für Windows Server 2003 R2

Dieses SDK enthält eine Version der CRT, die von den DST 2007-Änderungen betroffen ist. Kunden müssen die Versionshinweise für dieses SDK befolgen und bei Bedarf die Visual Studio 2005 CRT-Updates verwenden.

Auswirkungen von DST 2007 auf das .NET Framework 2.0 SDK

Dieses SDK enthält eine Version der CRT, die von den DST 2007-Änderungen betroffen ist. Im Rahmen der Installation dieses SDK können Sie visual Studio 2005 CRT auf Computern installieren, auf denen diese Version der CRT noch nicht installiert ist. Wenn bereits eine neuere Version der CRT installiert ist, überschreibt die SDK-Installation diese neuere Version nicht. Wenn das SDK deinstalliert wird, bleibt die neueste Version von CRT auf dem Computer. Sie können das Visual Studio 2005 CRT-Update entweder vor oder nach der Installation des SDK installieren.

Lokale Zeitkonvertierung in Windows

Anwendungen konvertieren in der Regel UTC-Zeiten in Ortszeiten, bevor sie zeit- und datumsinformationen für den Benutzer anzeigen. Windows bietet mehrere APIs für Anwendungen, die für die Zeitstempelbearbeitung verwendet werden können.

  • Die GetSystemTime() Funktion und die GetSystemTimeAsFileTime() Funktion rufen die aktuelle UTC-Zeit in einer SYSTEMTIME -Struktur oder in einer -Struktur ab FILETIME .

  • Die GetLocalTime() Funktion ruft die aktuelle Ortszeit in einer SYSTEMTIME -Struktur ab.

  • Die GetTimeZoneInformation() Funktion ruft eine TIME_ZONE_INFORMATION Struktur ab, die die aktuelle Zeitzone und die DST-Einstellung für den Computer beschreibt.

  • Die SystemTimeToFileTime() Funktion und die FileTimeToSystemTime() Funktion marshallen zwischen SYSTEMTIME Strukturen und FILETIME Strukturen.

  • Die FileTimeToLocalFileTime() Funktion und die LocalFileTimeToFileTime() Funktion konvertieren und übersetzen eine FILETIME Struktur zwischen UTC und Ortszeit mithilfe der aktuellen Zeitzone und der DST-Einstellung auf dem Computer.

  • Die SystemTimeToTzSpecificLocalTime() Funktion und die TzSpecificTimeToSystemTime() Funktion konvertieren einen UTC-Zeitstempel in einer SYSTEMTIME -Struktur in eine lokale SYSTEMTIME Struktur. Diese Funktionen verwenden eine TIME_ZONE_INFORMATION -Struktur, die das Startdatum und das Enddatum für die Sommerzeit angibt. Standardmäßig werden die aktuellen DST-Regeln verwendet, wenn keine solche Struktur bereitgestellt wird.

  • Die NetRemoteTOD() Funktion ruft die Zeit von einem Remoteserver mithilfe der Informationen und Einstellungen des Servers ab.

Hinweis

Die FileTimeToLocalFileTime() -Funktion und die LocalFileTimeToFileTime() -Funktion führen die Konvertierung zwischen UTC-Zeit und Ortszeit aus, indem nur die aktuellen Zeitzoneninformationen und die DST-Informationen verwendet werden. Diese Konvertierung erfolgt unabhängig vom Zeitstempel, der konvertiert wird.

Um ein Beispiel für dieses Verhalten in Windows Explorer anzuzeigen, führen Sie die folgenden Schritte auf einem Computer aus, der sich in einer Zeitzone befindet, die DST verwendet.

Für diese Schritte müssen Sie die Systemuhr ändern. Daher müssen Sie alle Anwendungen beenden, z. B. Kalenderanwendungen, die möglicherweise auf diese Zeitänderungen reagieren, bevor Sie diese Schritte ausführen.

  1. Ändern Sie das Datum auf dem Computer in einen DST-Tag. Legen Sie beispielsweise das Datum auf den 1. Juli 2006 fest.
  2. Erstellen Sie in einem NTFS-Verzeichnis auf demselben Computer eine neue Textdatei mit dem Namen Test.txt.
  3. Beachten Sie, dass der Zeitstempel in der Datei in Windows Explorer wie folgt angezeigt wird:
    01.07.2006 15:37 Uhr
  4. Ändern Sie das Datum auf dem Computer in einen Nicht-DST-Tag. Legen Sie beispielsweise das Datum auf den 1. Februar 2007 fest.
  5. Aktualisieren Sie das Fenster windows Explorer.
  6. Beachten Sie, dass der Zeitstempel in der Datei in Windows Explorer wie folgt angezeigt wird:
    01.07.2006 14:37

In diesem vorherigen Beispiel ändert sich der UTC-Zeitstempel für die Datei nicht. Die Regeln, die zum Konvertieren des Zeitstempels in eine Ortszeit verwendet werden, ändern sich jedoch abhängig vom aktuellen Datum auf dem Computer. In Schritt 3 wurde ein DST-Offset angewendet, da der 1. Juli innerhalb des DST-Bereichs liegt. In Schritt 6 wurde kein DST-Offset angewendet, da der 1. Februar nicht innerhalb des DST-Bereichs liegt. Dieses Verhalten tritt auf, sodass der Zeitstempel der Datei deterministisch in die Ortszeit und von der Ortszeit konvertiert werden kann.

Die SystemTimeToTzSpecificLocalTime() -Methode und die TzSpecificTimeToSystemTime() -Methode werden mithilfe der bereitgestellten TIME_ZONE_INFORMATION -Struktur zwischen UTC-Zeit und Ortszeit konvertiert. Wenn keine Zeitzoneninformationen bereitgestellt werden, verwenden diese Funktionen die aktuellen Zeitzonenregeln und die DST-Regeln, um zu bestimmen, ob ein DST-Offset auf den Zeitstempel angewendet werden muss. Dies entspricht funktional dem Aufrufen der GetTimeZoneInformation() -Methode zum Abrufen der TIME_ZONE_INFORMATION derzeit gültigen Struktur.

Die TIME_ZONE_INFORMATION Struktur enthält das Startdatum und das Enddatum für die Sommerzeit. Wenn die TIME_ZONE_INFORMATION -Struktur die aktuellen Zeitzoneninformationen verwendet, kann die TIME_ZONE_INFORMATION Struktur daher zu einer historischen Ungenauigkeit führen. Dieses Verhalten kann auftreten, wenn die aktuellen Zeitzoneninformationen und die DST-Informationen nicht den Zeitstempel widerspiegeln, der konvertiert wird. Dieses Verhalten wird von der DST 2007 nur beeinflusst, weil die Regeln geändert wurden, die die Datumsangaben für den Start und das Beenden der Sommerzeit regeln.

Um historisch genaue Konvertierungen aus diesen Funktionen zu erhalten, muss eine Anwendung eine historisch genaue TIME_ZONE_INFORMATION Struktur bereitstellen, wenn die Anwendung diese Funktionen aufruft.

Dynamische Zeitzonen in Windows

Windows Vista führt dynamische DST-Zeitzonen ein. Die dynamische Sommerzeit bietet Unterstützung für Zeitzonen, deren Grenzen für die Gültigkeitsdauer von Jahr zu Jahr geändert werden. Diese Regeln werden in der Registrierung gespeichert. Anwendungen können die Regeln mithilfe der GetDynamicTimeZoneInformation() -Funktion abfragen.

Dynamische Zeitzonen ermöglichen eine einfachere Aktualisierung von Computern, insbesondere für Gebietsschemas, in denen die jährliche DST-Grenzen im Voraus bekannt sind. Weitere Informationen zur DYNAMIC_TIME_ZONE_INFORMATION Struktur im Windows SDK für Vista finden Sie unter DYNAMIC_TIME_ZONE_INFORMATION-Struktur.

Lokale Zeitkonvertierung in der C-Runtime (CRT)

Die CRT verfügt im Wesentlichen über drei Modi, in denen Zeitstempel übersetzt werden können:

  • Wenn die TZ-Umgebungsvariable nicht festgelegt ist, ruft die CRT die Windows-APIs auf und weist ein Windows-Verhalten auf, wie in diesem Artikel beschrieben.

  • Wenn die TZ-Umgebungsvariable festgelegt ist, führt die CRT eigene Konvertierungen durch, die auf dieser Einstellung basieren. Die CRT wird aktualisiert, sodass sie die neuen DST 2007-Regeln beachtet, wenn sie konvertierungen in diesem Szenario durchführt.

  • Wenn die TZ-Umgebungsvariable nicht festgelegt ist, aber die zugrunde liegenden Windows-APIs fehlschlagen, greift die CRT auf ihre eigenen Konvertierungen zurück, indem der Wert PST8PDT für die TZ-Umgebungsvariable verwendet wird.

Die CRT enthält eine eigene Logik für die Konvertierung von UTC in Ortszeit. Anwendungen können UTC-Zeitstempel von Funktionen wie der time() -Funktion abrufen. Diese UTC-Zeitstempel werden in time_t Werten gespeichert. Die Konvertierung in die Ortszeit kann mit einer Funktion wie der localtime_s() -Funktion durchgeführt werden. Die localtime_s() Funktion füllt eine tm Struktur auf, die in der Time.h Headerdatei definiert ist. Die tm -Struktur basiert auf der Zeitzone, die in der TZ-Umgebungsvariable definiert ist, und auf den DST-Regeln, die zum Zeitpunkt des Zeitstempels in Kraft sind.

Hinweis

Diese Konvertierung folgt speziellen Regeln für die USA.

Bevor Sie das DST 2007-Update anwenden, verarbeitet die CRT aktuelle Zeitstempel in USA Zeitzonen ordnungsgemäß. Nachdem Sie das DST 2007-Update angewendet haben, verarbeitet die CRT auch vergangene und zukünftige USA Datumsangaben. Updates für die CRT sind im Abschnitt Verweise aufgeführt.

Lokale Zeitkonvertierung im .NET Framework

Die .NET Framework enthält Klassen, die Zeitstempel speichern und konvertieren. Zu diesen Klassen gehören die DateTime -Klasse, die TimeZone -Klasse, die TimeSpan -Klasse und die - DateTimeKind Klasse. Wie bereits erwähnt, hängen diese Klassen in erster Linie von der zugrunde liegenden Plattformimplementierung ab. Diese Klassen weisen das gleiche Verhalten wie die zugrunde liegenden Betriebssystem-APIs auf.

Ein interessantes Verhalten der .NET Framework Datums- und Zeitklassen bezieht sich auf die Funktionen, die den Zeitstempel um einen angeforderten Betrag verrechnen. Betrachten Sie beispielsweise die AddHours() -Funktion, die AddMinutes() -Funktion und die AddSeconds() -Funktion in der DateTime -Klasse. Diese Funktionen und ähnlich benannte Funktionen inkrementieren den Zeitstempel lediglich um den angeforderten Betrag ohne Berücksichtigung der DST-Einstellungen. Dieses Verhalten kann als einfache Arithmetik für den zugrunde liegenden UTC-Zeitstempel betrachtet werden. Dieses Verhalten kann jedoch zu unerwarteten Ergebnissen führen, wenn die Hinzufügung dazu führt, dass der Zeitstempel in die DST übergeht oder aus ihr herausgeht. Dieses Verhalten steht in keinem Zusammenhang mit änderungen an der Sommerzeit 2007.

Empfehlungen

Die folgenden Empfehlungen können Entwicklern helfen, die Auswirkungen von DST 2007 zu minimieren und die allgemeine Behandlung von Datum und Uhrzeit zu verbessern.

  • Sie sollten eine nahezu atomische Installation der DST 2007-Updates planen. Alle geplanten DST 2007-Updates sollten so nah wie möglich aufeinander angewendet werden. Wenn ein computer, der aktualisiert wurde, versucht, Methoden wie SQL-Abfragen oder Webdienste für die Kommunikation mit einem Computer zu verwenden, der nicht aktualisiert wurde, können Übersetzungsfehler auftreten. Wenn ein einzelner Computer zwei oder mehr Updates benötigt, z. B. das Windows-Update und das CRT-Update, sollten die Updates gleichzeitig angewendet werden.

  • UTC-Zeitstempel sind historisch genau. Die meisten Anwendungen betreffen in der Regel die Konvertierung in die Ortszeit. Anwendungen sollten immer UTC-Zeitstempel speichern. Konvertierungen in ortszeit für Anzeigezwecke erfordern Zeitzoneninformationen und DST-Informationen. Diese Informationen können aus verschiedenen Quellen stammen:

    • Die Anwendung kann die aktuelle Zeitzone und die DST-Einstellung für die Konvertierung verwenden. Dies kann zu Ungenauigkeiten bei der Konvertierung führen, wenn die aktuelle Zeitzone und die DST-Einstellung zum Zeitpunkt des Zeitstempels nicht wirksam waren.

    • Die Anwendung kann zusätzlich zum UTC-Zeitstempel die zuvor genauen Zeitzoneninformationen und DST-Informationen speichern.

    • Wenn dynamische Zeitzonen verfügbar sind, kann die Anwendung dynamische Zeitzonen verwenden, um zu bestimmen, welche Zeitzoneninformationen auf einen bestimmten UTC-Zeitstempel angewendet werden sollen. Diese Option ist nur verfügbar, wenn die dynamischen Zeitzoneninformationen für einen bestimmten Zeitstempel und für eine bestimmte Zeitzone verfügbar sind.

    • Die Anwendung kann einen lokalen Zeitstempel und den UTC-Zeitstempel speichern. Diese Methode verhindert, dass zukünftige Konvertierungen erforderlich sind.

  • Jede Kommunikation zwischen Computern, die mit Zeitstempeln arbeiten, sollte UTC-Zeitstempel verwenden. Dadurch erhalten beide Computer implizit dieselben Kontextinformationen für UTC.

  • Wenn eine Anwendung Datumsangaben verarbeitet, sollten Sie mit der Art und Weise vorsichtig sein, wie die Datumsangaben im Test behandelt werden. Datumsangaben, die ohne Zeitinformationen angezeigt werden, werden in der Regel als Zeitstempel von 12:00 Uhr am relevanten Datum gespeichert. Daher kann ein Fehler vom Typ "Off-by-One" im Stundenteil des Zeitstempels dazu führen, dass das Effektive Datum nach 1 fällt, wenn die Uhrzeit auf 23:00 Uhr des Vortags verschoben wird.

References