Bewährte Methoden zum Codieren mit DateTime im .NET Framework

Artikel
04/30/2007

Dan Rogers
Microsoft Corporation

Februar 2004

Gilt für:
   Microsoft® .NET Framework
   Microsoft® ASP.NET-Webdienste
   XML-Serialisierung

Zusammenfassung: Das Schreiben von Programmen, die Zeitwerte mit dem DateTime-Typ im Microsoft .NET Framework speichern, berechnen und serialisieren, erfordert eine Kenntnis der verschiedenen Probleme im Zusammenhang mit zeitdarstellungen, die in Windows und .NET verfügbar sind. Dieser Artikel konzentriert sich auf wichtige Test- und Entwicklungsszenarien mit Zeit und definiert die Empfehlungen zu bewährten Methoden für das Schreiben von Programmen, die den DateTime-Typ in Microsoft verwenden. NET-basierte Anwendungen und Assemblys. (18 gedruckte Seiten)

Inhalte

Hintergrund
   Was ist ein DateTime-Wert?
   Die Regeln
Speicherstrategien
   Bewährte Methode Nr. 1
   Bewährte Methode Nr. 2
Ausführen von Berechnungen
   Lassen Sie sich nicht wieder täuschen
   Bewährte Methode Nr. 3
   Sortierung von DateTime-Methoden
Der Sonderfall von XML
   Bewährte Methode Nr. 4
   Bewährte Methode #5
Quandary der Klassencoder
   Bewährte Methode #6
Umgang mit Sommerzeit
   Bewährte Methode #7
Formatieren und Analysieren von User-Ready Werten
   Zukünftige Überlegungen
Probleme mit der DateTime.Now()-Methode
   Bewährte Methode #8
Ein paar wenig bekannte Extras
Schlussbemerkung

Hintergrund

Viele Programmierer stoßen auf Zuweisungen, bei denen sie Daten mit Datums- und Uhrzeitinformationen genau speichern und verarbeiten müssen. Auf den ersten Blick scheint der DateTime-Datentyp der Common Language Runtime (CLR) für diese Aufgaben perfekt zu sein. Es ist jedoch nicht ungewöhnlich für Programmierer, aber wahrscheinlichere Tester, Fälle zu finden, in denen ein Programm einfach den Überblick über die richtigen Zeitwerte verliert. Dieser Artikel konzentriert sich auf Probleme im Zusammenhang mit der Logik, die DateTime betrifft. Dabei werden bewährte Methoden zum Schreiben und Testen von Programmen zum Erfassen, Speichern, Abrufen und Übertragen von DateTime-Informationen ermittelt.

Was ist ein DateTime-Wert?

Wenn wir uns die Dokumentation zur NET Framework-Klassenbibliothek ansehen, sehen wir, dass "Der CLR-Werttyp System.DateTime Datumsangaben und Uhrzeiten im Bereich von 12:00:00 Mitternacht, 1. Januar 0001 AD bis 23:59:59 Uhr, 31. Dezember 9999 AD darstellt." Wenn wir weiter lesen, erfahren wir nicht überraschend, dass ein DateTime-Wert einen Moment zu einem bestimmten Zeitpunkt darstellt, und dass es üblich ist, Point-in-Time-Werte in koordinierter Weltzeit (COORDINATED Universal Time, UCT) aufzuzeichnen , besser bekannt als Greenwich Mean Time (GMT).

Auf den ersten Blick erkennt ein Programmierer dann, dass ein DateTime-Typ ziemlich gut darin ist, Zeitwerte zu speichern, die wahrscheinlich bei aktuellen Programmierproblemen auftreten, z. B. in Geschäftsanwendungen. Mit dieser Zuversicht beginnt viele ahnungslose Programmierer mit dem Programmieren, in der Gewissheit, dass sie so viel lernen können, wie sie benötigen, um in etwa die Zeit zu gehen. Dieser "Learn-as-you-go"-Ansatz kann Sie zu einigen Problemen führen, also beginnen wir, sie zu identifizieren. Sie reichen von Problemen in der Dokumentation bis hin zu Verhaltensweisen, die in Ihren Programmdesigns berücksichtigt werden müssen.

Die V1.0- und 1.1-Dokumentation für System.DateTime enthält einige Generalisierungen, die den ahnungslosen Programmierer aus der Bahn werfen können. Für instance besagt die Dokumentation derzeit noch, dass die Methoden und Eigenschaften der DateTime-Klasse bei Berechnungen oder Vergleichen immer davon ausgehen, dass der Wert die lokale Zeitzone des lokalen Computers darstellt. Diese Generalisierung erweist sich als falsch, da es bestimmte Arten von Datums- und Uhrzeitberechnungen gibt, die GMT annehmen, und andere, die eine lokale Zeitzonenansicht annehmen. Auf diese Bereiche wird weiter unten in diesem Artikel hingewiesen.

Beginnen wir also mit dem DateTime-Typ, indem wir eine Reihe von Regeln und bewährten Methoden gliedern, die Ihnen helfen können, Ihren Code beim ersten Mal ordnungsgemäß zu funktionieren.

Die Regeln

Berechnungen und Vergleiche von DateTime-Instanzen sind nur sinnvoll, wenn es sich bei den verglichenen oder verwendeten Instanzen um Darstellungen von Zeitpunkten aus der gleichen Zeitzonenperspektive handelt.
Ein Entwickler ist dafür verantwortlich, zeitzonenbezogene Informationen, die einem DateTime-Wert zugeordnet sind, über einen externen Mechanismus nachzuverfolgen. In der Regel wird dies erreicht, indem Sie ein anderes Feld oder eine andere Variable definieren, die Sie zum Aufzeichnen von Zeitzoneninformationen verwenden, wenn Sie einen DateTime-Werttyp speichern. Dieser Ansatz (das Speichern des Zeitzonensinns neben dem DateTime-Wert) ist der genaueste und ermöglicht es verschiedenen Entwicklern an verschiedenen Punkten im Lebenszyklus eines Programms, immer ein klares Verständnis der Bedeutung eines DateTime-Werts zu haben. Ein weiterer gängiger Ansatz besteht darin, es zu einer "Regel" in Ihrem Entwurf zu machen, dass alle Zeitwerte in einem bestimmten Zeitzonenkontext gespeichert werden. Dieser Ansatz erfordert keinen zusätzlichen Speicher, um die Ansicht eines Benutzers im Zeitzonenkontext zu speichern, birgt jedoch das Risiko, dass ein Zeitwert von einem Entwickler falsch interpretiert oder falsch gespeichert wird, der die Regel nicht kennt.
Das Ausführen von Datums- und Uhrzeitberechnungen für Werte, die die lokale Computerzeit darstellen, liefert möglicherweise nicht immer das richtige Ergebnis. Beim Ausführen von Berechnungen für Zeitwerte in Zeitzonenkontexten, die Sommerzeit üben, sollten Sie Werte in universelle Zeitdarstellungen konvertieren, bevor Sie datumsarithmetische Berechnungen durchführen. Eine bestimmte Liste der Vorgänge und ordnungsgemäßen Zeitzonenkontexte finden Sie in der Tabelle im Abschnitt Sortieren von DateTime-Methoden.
Eine Berechnung für einen instance eines DateTime-Werts ändert den Wert des instance nicht. Daher ändert ein Aufruf von MyDateTime.ToLocalTime() nicht den Wert des instance der DateTime. Die Methoden, die den Klassen Date (in Visual Basic®) und DateTime (in der .NET CLR) zugeordnet sind, geben neue Instanzen zurück, die das Ergebnis einer Berechnung oder eines Vorgangs darstellen.
Wenn Sie die .NET Framework Version 1.0 und 1.1 verwenden, senden Sie KEINEN DateTime-Wert, der die UCT-Zeit bis System.XML darstellt. Serialisierung. Dies gilt für Date-, Time- und DateTime-Werte. Stellen Sie bei Webdiensten und anderen Formen der Serialisierung in XML mit System.DateTime immer sicher, dass der Wert im DateTime-Wert die aktuelle Ortszeit des Computers darstellt. Das Serialisierungsprogramm decodiert ordnungsgemäß einen im XML-Schema definierten DateTime-Wert, der in GMT codiert ist (Offsetwert = 0), decodiert ihn jedoch mit dem lokalen Computerzeitpunkt.
Wenn Es sich im Allgemeinen um absolute verstrichene Zeit handelt, z. B. das Messen eines Timeouts, das Ausführen von Arithmetik oder das Durchführen von Vergleichen verschiedener DateTime-Werte, sollten Sie versuchen, nach Möglichkeit einen Universal-Zeitwert zu verwenden, damit Sie die bestmögliche Genauigkeit erhalten, ohne dass sich die Zeitzone und/oder die Sommerzeit auswirken.
Wenn Sie sich mit allgemeinen, benutzerseitigen Konzepten wie der Planung befassen und sicher davon ausgehen können, dass jeder Tag aus Benutzersicht 24 Stunden hat, kann es in Ordnung sein, Regel 6 durch Ausführen von Arithmetik et cetera zu Ortszeiten zu kontern.

In diesem Artikel dient diese einfache Liste von Regeln als Grundlage für eine Reihe bewährter Methoden zum Schreiben und Testen von Anwendungen, die Datumsangaben verarbeiten.

Inzwischen sehen sich mehrere von Ihnen bereits Ihren Code durch und sagen: "Oh verdammt, es tut nicht, was ich erwartet habe", was der Zweck dieses Artikels ist. Für diejenigen von uns, die bisher keine Epiphanie aus dem Lesen hatten, werfen wir einen Blick auf die Probleme im Zusammenhang mit der Verarbeitung von DateTime-Werten (von nun an werde ich dies in "Datumsangaben" kürzen) in . NET-basierte Anwendungen.

Speicherstrategien

Gemäß den obigen Regeln sind Berechnungen für Datumswerte nur dann sinnvoll, wenn Sie die Zeitzoneninformationen verstehen, die dem von Ihnen verarbeiteten Datumswert zugeordnet sind. Dies bedeutet, dass Sie als Programmierer für die Anwendung einer Strategie verantwortlich sind, die es Ihnen ermöglicht, die zugeordneten Zeitzoneninformationen zu einem späteren Zeitpunkt zu verstehen, unabhängig davon, ob Sie Ihren Wert vorübergehend in einer Klassenmembervariablen speichern oder die gesammelten Werte in einer Datenbank oder Datei speichern möchten.

Bewährte Methode Nr. 1

Speichern Sie beim Programmieren die Zeitzoneninformationen, die einem DateTime-Typ zugeordnet sind, in einer zusatzlichen Variablen.

Eine alternative, aber weniger zuverlässige Strategie besteht darin, eine standhafte Regel zu erstellen, dass Ihre gespeicherten Daten vor der Speicherung immer in eine bestimmte Zeitzone wie GMT konvertiert werden. Dies mag sinnvoll erscheinen, und viele Teams können es schaffen. Das Fehlen eines eindeutigen Signals, das besagt, dass sich eine bestimmte DateTime-Spalte in einer Tabelle in einer Datenbank in einer bestimmten Zeitzone befindet, führt jedoch immer zu Interpretationsfehlern in späteren Iterationen eines Projekts.

Eine gemeinsame Strategie, die in einer informellen Umfrage verschiedener gesehen wird. NET-basierte Anwendungen sind der Wunsch, daten immer in der universellen Zeit (GMT) dargestellt zu haben. Ich sage "Begehren", weil dies nicht immer praktisch ist. Bei der Serialisierung einer Klasse, die über eine DateTime-Membervariable verfügt, über einen Webdienst tritt ein Fall auf. Der Grund dafür ist, dass ein DateTime-Werttyp einem XSD:DateTime-Typ zugeordnet ist (wie zu erwarten), und der XSD-Typ die Darstellung von Zeitpunkten in jeder Zeitzone. Der XML-Fall wird später erläutert. Interessanter ist, dass ein guter Prozentsatz dieser Projekte ihr Ziel nicht erreicht hat und die Datumsinformationen in der Serverzeitzone gespeichert haben, ohne es zu merken.

In diesen Fällen ist eine interessante Tatsache, dass die Tester keine Probleme mit der Zeitkonvertierung erkannt haben, sodass niemand bemerkt hatte, dass der Code, der die lokalen Datumsinformationen in die UCT-Zeit konvertieren sollte, fehlschlägt. In diesen speziellen Fällen wurden die Daten später über XML serialisiert und ordnungsgemäß konvertiert, da sich die Datumsinformationen zu Beginn in der Ortszeit des Computers befanden.

Sehen wir uns code an , der nicht funktioniert:

Dim d As DateTime
d = DateTime.Parse("Dec 03, 2003 12:00:00 PM") 'date assignment
d.ToUniversalTime()

Das obige Programm akzeptiert den Wert in der Variablen d und speichert ihn in einer Datenbank, wobei erwartet wird, dass der gespeicherte Wert eine UCT-Zeitansicht darstellt. In diesem Beispiel wird erkannt, dass die Parse-Methode das Ergebnis in der Ortszeit rendert, es sei denn, eine nicht standardmäßige Kultur wird als optionales Argument für die Parse-Methodenfamilie verwendet.

Der zuvor gezeigte Code kann den Wert in der DateTime-Variablen d in der dritten Zeile tatsächlich nicht in universelle Zeit konvertieren, da das Beispiel, wie geschrieben, gegen Regel 4 verstößt (die Methoden der DateTime-Klasse konvertieren den zugrunde liegenden Wert nicht). Hinweis: Dieser Code wurde in einer tatsächlich getesteten Anwendung angezeigt.

Wie ist es passiert? Die beteiligten Anwendungen konnten die gespeicherten Datumsangaben erfolgreich vergleichen, da während des Tests alle Daten von Computern stammen, die auf dieselbe Zeitzone festgelegt wurden, sodass Regel 1 erfüllt wurde (alle Daten, die verglichen und berechnet werden, werden auf die gleiche Zeitzonensicht lokalisiert). Der Fehler in diesem Code ist die Art, die schwer zu erkennen ist – eine Anweisung, die ausgeführt wird, aber nichts bewirkt (Hinweis: Die letzte Anweisung im Beispiel ist eine no-op, wie geschrieben).

Bewährte Methode Nr. 2

Überprüfen Sie beim Testen, ob gespeicherte Werte den gewünschten Point-in-Time-Wert in der gewünschten Zeitzone darstellen.

Das Beheben des Codebeispiels ist einfach:

Dim d As DateTime
d = DateTime.Parse("Dec 03, 2003 12:00:00 PM").ToUniversalTime()

Da sich die dem DateTime-Werttyp zugeordneten Berechnungsmethoden nie auf den zugrunde liegenden Wert auswirken, sondern stattdessen das Ergebnis der Berechnung zurückgeben, muss sich ein Programm daran erinnern, den konvertierten Wert zu speichern (wenn dies natürlich gewünscht ist). Als Nächstes untersuchen wir, wie selbst diese scheinbar richtige Berechnung unter bestimmten Umständen mit Sommerzeit nicht die erwarteten Ergebnisse erzielen kann.

Ausführen von Berechnungen

Auf den ersten Blick sind die Berechnungsfunktionen, die mit der System.DateTime-Klasse enthalten sind, wirklich nützlich. Es wird Unterstützung für das Hinzufügen von Intervallen zu Zeitwerten, das Ausführen von Arithmetik für Zeitwerte und sogar das Konvertieren von .NET-Zeitwerten in den entsprechenden Werttyp bereitgestellt, der für Win32-API-Aufrufe® sowie OLE-Automatisierungsaufrufe geeignet ist. Ein Blick auf die Unterstützungsmethoden, die den DateTime-Typ umgeben, weckt einen nostalgischen Blick auf die verschiedenen Methoden, die MS-DOS® und Windows® für den Umgang mit Zeit und Zeitstempeln im Laufe der Jahre entwickelt haben.

Die Tatsache, dass alle diese Komponenten noch in verschiedenen Teilen des Betriebssystems vorhanden sind, hängt mit den Abwärtskompatibilitätsanforderungen zusammen, die Microsoft verwaltet. Für einen Programmierer bedeutet dies, dass Sie, wenn Sie Daten verschieben, die Zeitstempel in Dateien, Verzeichnissen darstellen, oder COM/OLE-Interop mit date- und DateTime-Werten ausführen, Sie mit Konvertierungen zwischen den verschiedenen Zeitgenerationen vertraut werden müssen, die in Windows vorhanden sind.

Lassen Sie sich nicht wieder täuschen

Angenommen, Sie haben die Strategie "Wir speichern alles in UCT-Zeit" angenommen, vermutlich um den Mehraufwand zu vermeiden, dass ein Zeitzonenoffset (und vielleicht eine beäugte Ansicht der Zeitzone, z. B. Pacific Standard Time oder PST), gespeichert werden muss. Die Durchführung von Berechnungen mit UCT-Zeit hat mehrere Vorteile. Haupt unter ihnen ist die Tatsache, dass jeder Tag, wenn er in universaler Zeit dargestellt wird, eine feste Länge hat und keine Zeitzonenoffsets zu behandeln sind.

Wenn Sie überrascht waren zu lesen, dass ein Tag unterschiedliche Längen haben kann, beachten Sie, dass Tage in jeder Zeitzone, die Sommerzeit ermöglicht, an zwei Tagen im Jahr (in der Regel) eine andere Länge haben. Selbst wenn Sie also einen Ortszeitwert verwenden, z. B. Pacific Standard Time (PST), wenn Sie versuchen, einem bestimmten DateTime-instance Wert eine Zeitspanne hinzuzufügen, erhalten Sie möglicherweise nicht das Gewünschte Ergebnis, wenn das hinzugefügte Intervall die Änderungszeit an einem Datum übergeht, an dem die Sommerzeit entweder beginnt oder endet.

Sehen wir uns ein Beispiel für Code an, der in der Pacific Time Zone im USA nicht funktioniert:

Dim d As DateTime
d = DateTime.Parse("Oct 26, 2003 12:00:00 AM") 'date assignment
d = d.AddHours(3.0)
' - displays 10/26/2003 03:00:00 AM – an ERROR!
MsgBox(d.ToString)

Das Ergebnis, das aus dieser Berechnung angezeigt wird, mag auf den ersten Blick korrekt erscheinen; am 26. Oktober 2003, eine Minute nach 1:59 Uhr PST, trat jedoch die Sommerzeitänderung in Kraft. Die richtige Antwort hätte am 26.10.2003, 02:00:00 Uhr lauten müssen, sodass diese Berechnung, die auf einem Ortszeitwert basiert, nicht das richtige Ergebnis lieferte. Aber wenn wir auf Regel Nr. 3 zurückschauen, scheinen wir einen Widerspruch zu haben, aber wir nicht. Nennen wir es einfach einen Sonderfall für die Verwendung der Add/Subtrah-Methoden in Zeitzonen, in denen die Sommerzeit gefeiert wird.

Bewährte Methode Nr. 3

Seien Sie beim Programmieren vorsichtig, wenn Sie DateTime-Berechnungen (add/subtrahieren) für Werte ausführen müssen, die Zeitzonen darstellen, in denen die Sommerzeit praktiziert wird. Unerwartete Berechnungsfehler können auftreten. Konvertieren Sie stattdessen den Lokalen Zeitwert in die Universelle Zeit, führen Sie die Berechnung aus, und konvertieren Sie zurück, um eine maximale Genauigkeit zu erzielen..

Das Beheben dieses fehlerhaften Codes ist einfach:

Dim d As DateTime
d = DateTime.Parse("Oct 26, 2003 12:00:00 AM") 'date assignment
d = d.ToUniversalTime().AddHours(3.0).ToLocalTime()
' - displays 10/26/2003 02:00:00 AM – Correct!
MsgBox(d.ToString)

Die einfachste Möglichkeit, Zeitspannen zuverlässig hinzuzufügen, besteht darin, lokal-zeitbasierte Werte in universelle Zeit zu konvertieren, die Berechnungen durchzuführen und dann die Werte wieder zu konvertieren.

Sortierung von DateTime-Methoden

In diesem Artikel werden verschiedene System.DateTime-Klassenmethoden erläutert. Einige liefern ein korrektes Ergebnis, wenn der zugrunde liegende instance die Ortszeit darstellt, andere die Weltzeit darstellen, und andere erfordern immer noch keine zugrunde liegende instance. Darüber hinaus sind einige völlig unabhängig von der Zeitzone (z. B. AddYear, AddMonth). Um das allgemeine Verständnis der Annahmen hinter den am häufigsten gefundenen DateTime-Unterstützungsmethoden zu vereinfachen, wird die folgende Tabelle bereitgestellt.

Um die Tabelle zu lesen, berücksichtigen Sie den Anfangs- (Eingabe) und endenden (zurückgegebenen Wert). In allen Fällen wird der Endzustand des Aufrufens einer Methode von der -Methode zurückgegeben. Es wird keine Konvertierung in die zugrunde liegende instance der Daten durchgeführt. Es werden auch Einschränkungen bereitgestellt, die Ausnahmen oder nützliche Anleitungen beschreiben.

Methodenname	Ausgangspunkt	Endsicht	Vorbehalte
Touniversaltime	Ortszeit	UTC	Rufen Sie nicht für eine DateTime-instance auf, die bereits die Weltzeit darstellt.
Tolocaltime	UTC	Ortszeit	Rufen Sie nicht für eine DateTime-instance auf, die bereits die Ortszeit darstellt.
Tofiletime	Ortszeit		Die -Methode gibt einen INT64-Wert zurück, der die Win32-Dateizeit (UCT-Zeit) darstellt.
FromFileTime		Ortszeit	Statische Methode– keine instance erforderlich. Verwendet eine INT64 UCT-Zeit als Eingabe
ToFileTimeUtc (nur V1.1)	UTC		Die -Methode gibt einen INT64-Wert zurück, der eine Win32-Dateizeit (UCT-Zeit) darstellt.
FromFileTimeUtc (nur V1.1)		UTC	Die Methode konvertiert die INT64 Win32-Dateizeit in eine DateTime UCT-instance
jetzt		Ortszeit	Statische Methode– keine instance erforderlich. Gibt einen DateTime-Wert zurück, der die aktuelle Uhrzeit in der Lokalen Computerzeit darstellt.
UtcNow		UTC	Statische Methode – keine instance erforderlich
IsLeapYear	Ortszeit		Gibt einen booleschen Wert zurück, der true angibt, wenn der Jahresteil der Ortszeit instance ein Schaltjahr ist.
Heute		Ortszeit	Statische Methode– keine instance erforderlich. Gibt einen DateTime-Wert zurück, der auf Mitternacht des aktuellen Tages in der Lokalen Computerzeit festgelegt ist.

Der Sonderfall von XML

Mehrere Personen, mit denen ich kürzlich gesprochen habe, hatten das Entwurfsziel, Zeitwerte über Webdienste zu serialisieren, sodass die XML, die die DateTime darstellt, in GMT formatiert wird (z. B. mit einem Nulloffset). Obwohl ich verschiedene Gründe gehört habe, von dem Wunsch, das Feld einfach als Textzeichenfolge für die Anzeige in einem Client zu analysieren, um die Annahmen "in UCT gespeichert" beizubehalten, die auf dem Server vorhanden sind, bis hin zu den Aufrufern von Webdiensten, war ich nicht überzeugt, dass es jemals einen guten Grund gibt, das Marshallingformat auf der Leitung in diesem Maße zu steuern. Warum? Einfach, weil die XML-Codierung für einen DateTime-Typ perfekt geeignet ist, um eine sofortige Zeit darzustellen, und das xml-Serialisierungsprogramm, das in die .NET Framework integriert ist, übernimmt eine gute Aufgabe bei der Verwaltung der Serialisierungs- und Deserialisierungsprobleme im Zusammenhang mit Zeitwerten.

Darüber hinaus stellt sich heraus, dass das Erzwingen des System.XML. Serialisierungsserialisierung zum Codieren eines Datumswerts in GMT über die Leitung ist in .NET nicht möglich, zumindest heute nicht. Als Programmierer, Designer oder Projektmanager stellt Ihr Auftrag dann sicher, dass die Daten, die in Ihrer Anwendung übergeben werden, mit minimalen Kosten genau ausgeführt werden.

Einige der Gruppen, mit denen ich in der Forschung in diesem Artikel gesprochen habe, hatten die Strategie angenommen, spezielle Klassen zu definieren und ihre eigenen XML-Serialisierer zu schreiben, damit sie die volle Kontrolle darüber haben, wie die DateTime-Werte in ihrem XML-Code aussähen. Während ich den Rupf bewundere, den Entwickler haben, wenn sie den Sprung in dieses mutige Unternehmen machen, seien Sie sicher, dass die Nuancen der Behandlung von Sommerzeit- und Zeitzonenumwandlungsproblemen allein einen guten Manager sagen sollten, "Kein Weg", insbesondere wenn die in der .NET Framework bereitgestellten Mechanismen einen perfekt genauen Job der Serialisierung von Zeitwerten bereits machen.

Es gibt nur einen Trick, den Sie beachten müssen, und als Designer MÜSSEN Sie dies verstehen und sich an die Regel halten (siehe Regel #5).

Code, der nicht funktioniert:

Definieren wir zunächst eine einfache XML-Klasse mit einer DateTime-Membervariable. Aus Gründen der Vollständigkeit ist diese Klasse die vereinfachte Entsprechung des empfohlenen Ansatzes, der weiter unten im Artikel veranschaulicht wird.

<XmlType(TypeName:="timeTestDef", _
    Namespace:= "http://tempuri.org/Timetester.xsd")>), _
    XmlRoot(), Serializable()> _
Public Class timeTestDef
    Private __timeVal As DateTime

    <XmlIgnore()> _
    Public timeValSpecified As Boolean

    <XmlElement(ElementName:="timeVal", IsNullable:=False, _
        Form:=XmlSchemaForm.Qualified, DataType:="dateTime", _
        Namespace:="http://tempuri.org/Timetester.xsd")> _
    Public Property timeVal() As DateTime
        Get
            timeVal = __timeVal
        End Get
        Set(ByVal Value As DateTime)
            __timeVal = Value
            timeValSpecified = True
        End Set
    End Property
End Class

Nun verwenden wir diese Klasse, um XML in eine Datei zu schreiben.

' write out to the file
Dim t As Xml.XmlTextWriter
Dim ser As XmlSerializer
Dim tt As New timeTest ' a class that has a DateTime variable
' set the fields in your class
tt.timeVal = DateTime.Parse("12/12/2003 12:01:02 PM")
tt.timeVal = tt.TimeVal.ToUniversalTime()

' get a serializer for the root type, and serialize this UTC time
ser = New XmlSerializer(GetType(timeTest))
t = New Xml.XmlTextWriter("c:\timetest.xml", System.Text.Encoding.UTF8)
ser.Serialize(t, tt)
t.Close()
t = Nothing
tt = Nothing

Wenn dieser Code ausgeführt wird, enthält der XML-Code, der in die Ausgabedatei serialisiert wird, wie folgt eine XML-DateTime-Darstellung:

<timeVal>2003-12-12T20:01:02.0000000-08:00</timeVal>

Dies ist ein Fehler: Der in der XML codierte Wert ist um acht Stunden deaktiviert! Da dies der Zeitzonenoffset meines aktuellen Computers ist, sollten wir misstrauisch sein. Betrachtet man die XML selbst, ist das Datum richtig, und das Datum 20:01:02 entspricht der Uhrzeit in London für meine eigene Mittagzeit, aber der Offsetteil ist für eine Uhr auf London nicht korrekt. Wenn der XML-Code wie die Londoner Zeit aussieht, sollte der Offset auch den Londoner Standpunkt darstellen, den dieser Code nicht erreicht.

Das XML-Serialisierungsprogramm geht immer davon aus, dass dateTime-Werte, die serialisiert werden, die lokale Computerzeit darstellen, sodass der lokale Zeitzonenoffset des Computers als Offsetteil der codierten XML-Zeit angewendet wird. Wenn wir dies auf einem anderen Computer deserialisieren, wird der ursprüngliche Offset vom analysierten Wert subtrahiert, und der Zeitzonenoffset des aktuellen Computers wird hinzugefügt.

Wenn wir mit einer Lokalen Zeit beginnen, ist das Ergebnis der Serialisierung (Codieren in XML-DateTime, gefolgt von der Decodierung in die lokale Computerzeit) immer richtig – aber nur, wenn der beginnende DateTime-Wert, der serialisiert wird, die lokale Zeit darstellt, wenn die Serialisierung beginnt. Im Fall dieses fehlerhaften Codebeispiels hatten wir bereits den DateTime-Wert in der TimeVal-Membervariable auf UCT-Zeit angepasst. Wenn wir also serialisieren und deserialisieren, wird das Ergebnis um die Anzahl der Stunden deaktiviert, die dem Zeitzonenoffset des Ausgangscomputers entspricht. Das ist schlecht.

Bewährte Methode Nr. 4

Berechnen Sie beim Testen den Wert, den Sie in der XML-Zeichenfolge erwarten, die mithilfe einer computerlokalen Zeitansicht des Zeitpunkts, zu dem getestet wird, serialisiert wird. Wenn sich der XML-Code im Serialisierungsdatenstrom unterscheidet, protokollieren Sie einen Fehler!

Das Beheben dieses Codes ist einfach. Kommentieren Sie die Zeile aus, die ToUniversalTime()aufruft.

Bewährte Methode #5

Beim Schreiben von Code zum Serialisieren von Klassen mit DateTime-Membervariablen müssen die Werte die lokale Zeit darstellen. Wenn sie keine Ortszeit enthalten, passen Sie sie vor jedem Serialisierungsschritt an, einschließlich der Übergabe oder Rückgabe von Typen, die DateTime-Werte in Webdiensten enthalten.

Quandary der Klassencoder

Zuvor haben wir uns eine ziemlich unausgeglichene Klasse angesehen, die eine DateTime-Eigenschaft verfügbar gemacht hat. In dieser Klasse haben wir einfach serialisiert, was wir in einer DateTime gespeichert haben, ohne zu berücksichtigen, ob der Wert einen lokalen oder universellen Zeitsichtpunkt darstellt. Sehen wir uns einen komplexeren Ansatz an, der Programmierern eine freie Wahl darüber bietet, welche Zeitzonenannahmen sie wünschen, während sie immer ordnungsgemäß serialisiert werden.

Beim Codieren einer Klasse, die über eine Membervariable vom Typ DateTime verfügt, hat ein Programmierer die Wahl, die Membervariable öffentlich zu machen oder die Eigenschaftenlogik zu schreiben, um die Membervariable mit get/set-Vorgängen zu umschließen. Die Auswahl, den Typ öffentlich zu machen, hat mehrere Nachteile, die im Fall von DateTime-Typen Folgen haben können, die nicht unter der Kontrolle des Klassenentwicklers liegen.

Wenn Sie das bisher Gelernte verwenden, sollten Sie stattdessen zwei Eigenschaften für jeden DateTime-Typ bereitstellen.

Das folgende Beispiel veranschaulicht den empfohlenen Ansatz zum Verwalten von DateTime-Membervariablen:

<XmlType(TypeName:="timeTestDef", _
    Namespace:= "http://tempuri.org/Timetester.xsd")>), _
    XmlRoot(), Serializable(), _
    EditorBrowsable(EditorBrowsableState.Advanced)> _
Public Class timeTestDef
    Private __timeVal As DateTime

    <XmlIgnore()> _
    Public timeValSpecified As Boolean

    <XmlElement(ElementName:="timeVal", IsNullable:=False, _
        Form:=XmlSchemaForm.Qualified, DataType:="dateTime", _
        Namespace:="http://tempuri.org/Timetester.xsd")> _
    Public Property timeVal() As DateTime
        Get
            timeVal = __timeVal.ToLocalTime()
        End Get
        Set(ByVal Value As DateTime)
            __timeVal = Value.ToUniversalTime()
            timeValSpecified = True
        End Set
    End Property

    <XmlIgnore()> _
    Public Property timeValUTC() As DateTime
        Get
            timeValUTC = __timeVal
        End Get
        Set(ByVal Value As DateTime)
            __timeVal = Value
            timeValSpecified = True
        End Set
    End Property
End Class

Dieses Beispiel ist das korrigierte Äquivalent zum vorherigen Beispiel für die Klassenserialisierung. In beiden Klassenbeispielen (hier und früher) handelt es sich bei den Klassen um Implementierungen, die mit dem folgenden Schema beschrieben werden:

<?xml version="1.0" encoding="utf-8" ?> 
<xs:schema id="Timetester" 
     targetNamespace="http://tempuri.org/Timetester.xsd"
     elementFormDefault="qualified"
     xmlns="http://tempuri.org/Timetester.xsd"
     xmlns:mstns="http://tempuri.org/Timetester.xsd"
     xmlns:xs="http://www.w3.org/2001/XMLSchema">

     <xs:element name="timeTest" type="timeTestDef"/>
     <xs:complexType name="timeTestDef">
      <xs:sequence>
         <xs:element name="timeVal" type="xs:dateTime"/>
      </xs:sequence>
     </xs:complexType>
</xs:schema>

In diesem Schema und in allen Klassenimplementierungen definieren wir eine Membervariable, die einen optionalen Zeitwert darstellt. In unserem empfohlenen Beispiel haben wir zwei Eigenschaften mit Gettern und Settern bereitgestellt– eine für die universelle Zeit und eine für die Ortszeit. Die im Code angezeigten attribute mit spitzen Klammern weisen das XML-Serialisierungsprogramm an, die Lokale Zeitversion für die Serialisierung zu verwenden, und führen im Allgemeinen zu einer schemakonformen Ausgabe der Klassenimplementierung. Damit die Klasse den optionalen Ausdrucksmangel ordnungsgemäß behandeln kann, wenn kein Wert in der instance festgelegt ist, steuert die variable timeValSpecified und die zugehörige Logik im Eigenschaftensetter, ob das XML-Element zur Serialisierungszeit ausgedrückt wird oder nicht. Dieses optionale Verhalten nutzt ein Feature im Serialisierungssubsystem, das für die Unterstützung optionaler XML-Inhalte konzipiert wurde.

Wenn Sie diesen Ansatz zum Verwalten von DateTime-Werten in Ihren .NET-Klassen verwenden, erhalten Sie das Beste aus beiden Welten– Sie erhalten Speicherzugriff basierend auf universeller Zeit, sodass die Berechnungen korrekt sind, und Sie erhalten eine ordnungsgemäße Serialisierung von Ortszeitansichten.

Bewährte Methode #6

Machen Sie beim Programmieren DateTime-Membervariablen privat, und stellen Sie zwei Eigenschaften zum Bearbeiten Ihrer DateTime-Member in lokaler oder universeller Zeit bereit. Legen Sie den Speicher im privaten Member als UCT-Zeit fest, indem Sie die Logik in Ihren Gettern und Settern steuern. Fügen Sie die XML-Serialisierungsattribute der Eigenschaftsdeklaration zur lokalen Zeit hinzu, um sicherzustellen, dass der Lokale Zeitwert serialisiert ist (siehe Beispiel).

Einschränkungen bei diesem Ansatz

Der empfohlene Ansatz für die Verwaltung einer DateTime in Universal Time innerhalb Ihrer privaten Membervariablen ist ebenso sinnvoll wie die Empfehlung, duale Eigenschaften bereitzustellen, damit Coder mit den Zeitversionen umgehen können, mit denen sie am besten vertraut sind. Ein Problem, das ein Entwickler verwendet, der diesen oder einen anderen Ansatz verwendet, der zu jeder Ortszeit für ein Programm verfügbar macht, ist weiterhin das 25-Stunden-Tag-Problem um die Sommerzeit. Dies ist weiterhin ein Problem für Programme, die DIE CLR-Version 1.0 und 1.1 verwenden, sodass Sie wissen müssen, ob Ihr Programm in diesen Sonderfall fällt (die hinzugefügte oder fehlende Stunde für die dargestellte Zeit), und manuell anpassen. Für diejenigen, die ein Ausgabefenster von einer Stunde pro Jahr nicht tolerieren können, empfiehlt es sich derzeit, Ihre Daten als Zeichenfolgen oder einen anderen selbstverwalteten Ansatz zu speichern. (Lange Unix-Ganzzahlen sind eine gute Option.)

Für CLR Version 2.0 (verfügbar in der kommenden Version von Visual Studio® code-named "Whidbey") wird dem .NET Framework bewusst, ob eine DateTime eine Ortszeit oder einen universellen Zeitwert enthält. Zu diesem Zeitpunkt funktioniert das empfohlene Muster weiterhin, aber für Programme, die über die UTC-Eigenschaften mit Membervariablen interagieren, werden diese Fehler im Zeitraum der fehlenden/zusätzlichen Stunde beseitigt. Aus diesem Grund wird die bewährte Methode für die Codierung mit dualen Eigenschaften heute dringend empfohlen, damit Ihre Programme sauber zu CLR-Version 2.0 migrieren.

Umgang mit Sommerzeit

Während wir uns darauf vorbereiten, das Thema Codierungs- und Testpraktiken für DateTime-Werte zu schließen und zu verlassen, bleibt ein Sonderfall, den Sie verstehen müssen. Dieser Fall umfasst die Mehrdeutigkeiten, die die Sommerzeit umgeben, und das wiederholte Problem mit einer Stunde pro Jahr. Dieses Problem betrifft in erster Linie nur Anwendungen, die Zeitwerte von Benutzereingaben erfassen.

Für diejenigen von Ihnen in der Länderzählungsmehrheit ist dieser Fall trivial, da in den meisten Ländern die Sommerzeit nicht praktiziert wird. Aber für diejenigen von Ihnen, die in der Mehrheit der betroffenen Programme sind (d. h. alle von Ihnen, die Anwendungen haben, die sich mit Zeit befassen müssen, die an Orten dargestellt oder an Orten bezogen werden können, die Sommerzeit üben), müssen Sie wissen, dass dieses Problem vorhanden ist und es berücksichtigen.

In Gegenden der Welt, in denen Sommerzeit praktiziert wird, gibt es pro Herbst und Frühling eine Stunde, in der die Zeit scheinbar vergeht. In der Nacht, in der die Zeit von normaler Zeit zu Tageslichtzeit wechselt, springt die Zeit eine Stunde voraus. Dies geschieht im Frühjahr. Im Herbst des Jahres, an einer Nacht, springt die Ortszeituhr eine Stunde zurück.

An diesen Tagen können Bedingungen auftreten, bei denen der Tag 23 oder 25 Stunden lang ist. Wenn Sie also Zeitspannen von Datumswerten hinzufügen oder subtrahieren und die Spanne diesen seltsamen Zeitpunkt überschreitet, an dem die Uhren wechseln, muss Ihr Code eine manuelle Anpassung vornehmen.

Bei Logik, die die DateTime.Parse() -Methode verwendet, um einen DateTime-Wert basierend auf der Benutzereingabe eines bestimmten Datums und einer bestimmten Uhrzeit zu berechnen, müssen Sie erkennen, dass bestimmte Werte ungültig sind (am 23-Stunden-Tag), und bestimmte Werte haben zwei Bedeutungen, da sich eine bestimmte Stunde wiederholt (am 25-Stunden-Tag). Um dies zu tun, müssen Sie die betreffenden Daten kennen und nach diesen Stunden suchen. Es kann hilfreich sein, die interpretierten Datumsinformationen zu analysieren und erneut anzuzeigen, wenn der Benutzer die felder verlässt, die zum Eingeben von Datumsangaben verwendet werden. Vermeiden Sie in der Regel, dass Benutzer die Sommerzeit in ihrer Eingabe angeben.

Wir haben bereits die bewährte Methode für Zeitspannenberechnungen behandelt. Wenn Sie Ihre Ortszeitansichten vor dem Ausführen Ihrer Berechnungen in universelle Zeit konvertieren, können Sie die Probleme mit der Zeitgenauigkeit überstehen. Der schwieriger zu verwaltende Fall ist der Mehrdeutigkeitsfall, der mit der Analyse von Benutzereingaben verbunden ist, die während dieser magischen Stunde im Frühjahr und Herbst auftritt.

Derzeit gibt es keine Möglichkeit, eine Zeichenfolge zu analysieren, die die Zeitansicht eines Benutzers darstellt, und ihr einen universellen Zeitwert genau zugewiesen zu haben. Der Grund ist, dass Menschen, die Sommerzeit erleben, nicht an Orten leben, an denen die Zeitzone Greenwich Mean Time ist. Daher ist es durchaus möglich, dass jemand, der an der Ostküste des USA, einen Wert wie "26. Oktober 2003 01:10:00 AM" eingibt.

An diesem bestimmten Morgen, um 2:00 Uhr, wird die lokale Uhr auf 1:00 Uhr zurückgesetzt, wodurch ein 25-Stunden-Tag entsteht. Da alle Werte der Uhrzeit zwischen 1:00 Uhr und 2:00 Uhr morgens zweimal an diesem bestimmten Morgen auftreten – zumindest in den meisten Usa und Kanada. Der Computer hat wirklich keine Möglichkeit zu wissen, welcher 1:10-Uhr-Tag gemeint war – die vor dem Schalter oder die, die 10 Minuten nach dem Sommerzeitschalter auftritt.

Ebenso müssen Ihre Programme mit dem Problem umgehen, das im Frühjahr auftritt, wenn es an einem bestimmten Morgen keine Zeit wie 2:10 Uhr gibt. Der Grund ist, dass um 2:00 Uhr an diesem bestimmten Morgen die Uhrzeit auf den lokalen Uhren plötzlich auf 3:00 Uhr ändert. Die gesamte 2:00-Stunde geschieht nie an diesem 23-Stunden-Tag.

Ihre Programme müssen mit diesen Fällen umgehen, möglicherweise indem sie den Benutzer auffordern, wenn Sie die Mehrdeutigkeit erkennen. Wenn Sie keine Datums-/Uhrzeit-Zeichenfolgen von Benutzern sammeln und analysieren, haben Sie diese Probleme wahrscheinlich nicht. Programme, die bestimmen müssen, ob eine bestimmte Zeit in die Sommerzeit fällt, können Folgendes nutzen:

Timezone.CurrentTimeZone.IsDaylightSavingTime(DateTimeInstance)

oder

DateTimeInstance.IsDaylightSavingTime

Bewährte Methode #7

Wenn Ihre Programme Benutzereingaben akzeptieren, die Datums- und Uhrzeitwerte angeben, stellen Sie beim Testen sicher, dass Sie an 23- und 25-Stunden-Tagen des Typs "Spring-ahead", "Fallback" auf Datenverluste testen. Stellen Sie außerdem sicher, dass Sie auf Daten testen, die auf einem Computer in einer Zeitzone erfasst und auf einem Computer in einer anderen Zeitzone gespeichert sind.

Formatieren und Analysieren von User-Ready Werten

Für Programme, die Datums- und Uhrzeitinformationen von Benutzern übernehmen und diese Benutzereingabe in DateTime-Werte konvertieren müssen, bietet das Framework Unterstützung für das Analysieren von Zeichenfolgen, die auf bestimmte Weise formatiert sind. Im Allgemeinen sind die DateTime.Parse - und ParseExact-Methoden nützlich, um Zeichenfolgen, die Datums- und Uhrzeitangaben enthalten, in DateTime-Werte zu konvertieren. Umgekehrt sind die Methoden ToString, ToLongDateString, ToLongTimeString, ToShortDateString und ToShortTimeString alle nützlich, um DateTime-Werte in lesbare Zeichenfolgen zu rendern.

Zwei Standard Probleme, die sich auf die Analyse auswirken, sind Kultur und Formatzeichenfolge. In den häufig gestellten Fragen (FAQ) zu DateTime werden die grundlegenden Probleme im Zusammenhang mit der Kultur behandelt. Daher konzentrieren wir uns hier auf die bewährten Methoden für Formatzeichenfolgen, die sich auf die DateTime-Analyse auswirken.

Die empfohlenen Formatzeichenfolgen zum Konvertieren von DateTime in Zeichenfolgen sind:

'yyyy'-'MM'-'dd'T'HH': 'mm': 'ss.fffffff'Z' — Für UCT-Werte

'yyyy'-'MM'-'dd'T'HH': 'mm': 'ss.fffffff'zzz' — Für lokale Werte

'yyyy'-'MM'-'dd'T'HH': 'mm': 'ss.fffffff' — Für abstrakte Zeitwerte

Dies sind die Formatzeichenfolgenwerte, die an die DateTime.ToString-Methode übergeben werden, wenn Sie eine Ausgabe erhalten möchten, die mit der XML-DateTime-Typspezifikation kompatibel ist. Die Anführungszeichen stellen sicher, dass die lokalen Datums-/Uhrzeiteinstellungen auf dem Computer Ihre Formatierungsoptionen nicht außer Kraft setzen. Wenn Sie unterschiedliche Layouts angeben müssen, können Sie andere Formatzeichenfolgen für eine recht flexible Datumsrenderingfunktion übergeben, aber Sie müssen darauf achten, nur die Z-Notation zu verwenden, um Zeichenfolgen aus UCT-Werten zu rendern, und die zzz-Notation für Ortszeitwerte zu verwenden.

Das Analysieren von Zeichenfolgen und deren Konvertierung in DateTime-Werte kann mit den Methoden DateTime.Parse und ParseExact erfolgen. Für die meisten von uns ist Parse ausreichend, da ParseExact erfordert, dass Sie Ihr eigenes Formatter-Objekt instance. Parse ist ziemlich fähig und flexibel und kann die meisten Zeichenfolgen, die Datums- und Uhrzeitangaben enthalten, genau konvertieren.

Schließlich ist es wichtig, die Methoden Parse und ToString immer nur nach dem Festlegen von CultureInfo des Threads auf CultureInfo.InvariantCulture aufzurufen.

Zukünftige Überlegungen

Eine Sache, die Sie derzeit nicht einfach mit DateTime.ToString tun können, ist das Formatieren eines DateTime-Werts in eine beliebige Zeitzone. Dieses Feature wird für zukünftige Implementierungen des .NET Framework in Betracht gezogen. Wenn Sie feststellen müssen, dass die Zeichenfolge "12:00:00 EST" "11:00:00 EDT" entspricht, müssen Sie die Konvertierung und den Vergleich selbst verarbeiten.

Probleme mit der DateTime.Now()-Methode

Es gibt mehrere Probleme beim Umgang mit der Methode namens Now. Für Visual Basic-Entwickler, die dies lesen, gilt dies auch für die Visual Basic Now-Funktion . Entwickler, die die Now-Methode regelmäßig verwenden, wissen, dass sie häufig verwendet wird, um die aktuelle Uhrzeit abzurufen. Der von der Now-Methode zurückgegebene Wert befindet sich im aktuellen Zeitzonenkontext des Computers und kann nicht als unveränderlicher Wert behandelt werden. Eine gängige Praxis besteht darin, Zeiten, die zwischen Computern gespeichert oder gesendet werden, in universelle Zeit (UCT) zu konvertieren.

Wenn die Sommerzeit eine Möglichkeit ist, gibt es eine Programmierpraxis, die Sie vermeiden sollten. Betrachten Sie den folgenden Code, der zu einem schwer zu erkennenden Fehler führen kann:

Dim timeval As DateTime
timeval = DateTime.Now().ToUniversalTime()

Der Wert, der sich aus der Ausführung dieses Codes ergibt, ist um eine Stunde deaktiviert, wenn er während der zusätzlichen Stunde aufgerufen wird, die während des Sommerzeitwechsels im Herbst auftritt. (Dies gilt nur für Computer, die sich in Zeitzonen befinden, die Sommerzeit üben.) Da die zusätzliche Stunde an der Stelle liegt, an der derselbe Wert, z. B. 1:10:00 Uhr, zweimal an diesem Morgen auftritt, stimmt der zurückgegebene Wert möglicherweise nicht mit dem gewünschten Wert überein.

Um dies zu beheben, besteht eine bewährte Methode darin, DateTime.UtcNow() anstelle von DateTime.Now aufzurufen und dann in universelle Zeit zu konvertieren.

Dim timeval As DateTime
timeval = DateTime.UtcNow()

Dieser Code hat immer die richtige 24-Stunden-Perspektive und kann dann sicher in die Ortszeit konvertiert werden.

Bewährte Methode #8

Wenn Sie programmieren und die aktuelle Zeit speichern möchten, die als universelle Zeit dargestellt wird, vermeiden Sie den Aufruf von DateTime.Now() gefolgt von einer Konvertierung in universelle Zeit. Rufen Sie stattdessen die DateTime.UtcNow-Funktion direkt auf.

Vorbehalt: Wenn Sie eine Klasse serialisieren möchten, die einen DateTime-Wert enthält, stellen Sie sicher, dass der wert, der serialisiert wird, nicht die Universelle Zeit darstellt. Die XML-Serialisierung unterstützt die UCT-Serialisierung erst ab dem Whidbey-Release von Visual Studio.

Ein paar wenig bekannte Extras

Manchmal, wenn Sie beginnen, in einen Teil einer API einzutauchen, finden Sie ein verstecktes Juwel – etwas, das Ihnen hilft, ein Ziel zu erreichen, das Sie jedoch, wenn Sie nicht darüber informiert werden, bei Ihren täglichen Reisen nicht aufdecken. Der Werttyp DateTime in .NET verfügt über mehrere solcher Edelsteine, die Ihnen helfen können, eine konsistentere Verwendung der universellen Zeit zu erzielen.

Die erste ist die DateTimeStyles-Enumeration , die im System.Globalization-Namespace gefunden wird. Die Enumeration steuert das Verhalten der Funktionen DateTime.Parse() und ParseExact, die zum Konvertieren von benutzerdefinierten Eingaben und anderen Formen von Eingabezeichenfolgendarstellungen in DateTime-Werte verwendet werden.

In der folgenden Tabelle werden einige der Features hervorgehoben, die die DateTimeStyles-Enumeration ermöglicht.

Enumerationskonstante	Zweck	Vorbehalte
AdjustToUniversal	Bei der Übergabe als Teil einer Parse- oder ParseExact-Methode bewirkt dieses Flag, dass der zurückgegebene Wert universelle Zeit ist.	Die Dokumentation ist mehrdeutig, aber dies funktioniert sowohl mit Parse als auch mit ParseExact.
NoCurrentDateDefault	Unterdrückt die Annahme, dass Zeichenfolgen, die ohne Datumskomponenten analysiert werden, einen DateTime-Wert zurückgegeben werden, der die Uhrzeit des aktuellen Datums ist.	Wenn diese Option verwendet wird, ist der zurückgegebene DateTime-Wert die am gregorianischen Datum 1. Januar im Jahr 1 angegebene Uhrzeit.
AllowWhiteSpaces Allowtrailingwhite AllowLeadingWhite AllowInnerWhite	Diese Optionen ermöglichen alle Toleranzen für hinzugefügte Leerzeichen vor, hinter und in der Mitte der zu analysierenden Datumszeichenfolgen.	Keine

AdjustToUniversal

Bei der Übergabe als Teil einer Parse- oder ParseExact-Methode bewirkt dieses Flag, dass der zurückgegebene Wert universelle Zeit ist.

Die Dokumentation ist mehrdeutig, aber dies funktioniert sowohl mit Parse als auch mit ParseExact.

NoCurrentDateDefault

Unterdrückt die Annahme, dass Zeichenfolgen, die ohne Datumskomponenten analysiert werden, einen DateTime-Wert zurückgegeben werden, der die Uhrzeit des aktuellen Datums ist.

Wenn diese Option verwendet wird, ist der zurückgegebene DateTime-Wert die am gregorianischen Datum 1. Januar im Jahr 1 angegebene Uhrzeit.

AllowWhiteSpaces

Allowtrailingwhite

AllowLeadingWhite

AllowInnerWhite

Diese Optionen ermöglichen alle Toleranzen für hinzugefügte Leerzeichen vor, hinter und in der Mitte der zu analysierenden Datumszeichenfolgen.

Keine

Weitere interessante Unterstützungsfunktionen finden Sie in der System.Timezone-Klasse . Überprüfen Sie diese, wenn Sie erkennen möchten, ob sich die Sommerzeit auf einen DateTime-Wert auswirkt, oder wenn Sie den aktuellen Zeitzonenoffset für den lokalen Computer programmgesteuert bestimmen möchten.

Schlussbemerkung

Die .NET Framework DateTime-Klasse bietet eine benutzeroberfläche mit vollem Funktionsumfang zum Schreiben von Programmen, die sich mit der Zeit befassen. Das Verständnis der Nuancen des Umgangs mit der Klasse geht über das hinaus, was Sie aus IntelliSense® gewinnen können. Hier behandelten wir die bewährten Methoden für das Programmieren und Testen von Programmen, die sich mit Datums- und Uhrzeitangaben befassen. Viel Spaß beim Programmieren!