Zum Hauptinhalt springen

5. Datums- und Zeitformat

Dieser Abschnitt erörtert wünschenswerte Eigenschaften von Datums- und Zeitformaten und definiert ein Profil von ISO 8601 für die Verwendung im Internet.

5.1. Ordering (Sortierung)​

Wenn Datums- und Zeitkomponenten von der am wenigsten präzisen zur präzisesten geordnet werden, wird eine nützliche Eigenschaft erreicht. Unter der Annahme, dass die Zeitzonen der Daten und Zeiten gleich sind (z.B. alle in UTC), unter Verwendung der gleichen Zeichenkette ausgedrückt werden (z.B. alle "Z" oder alle "+00:00"), und alle Zeiten die gleiche Anzahl von Bruchsekundenstellen haben, können Datums- und Zeitzeichenketten als Zeichenketten sortiert werden (z.B. unter Verwendung der strcmp()-Funktion in C) und erzeugen eine zeitlich geordnete Sequenz. Das Vorhandensein optionaler Interpunktion würde diese Eigenschaft verletzen.

Beispiel:

Korrekte Sortierung (Jahr-Monat-Tag Stunde:Minute:Sekunde):
2002-01-15T10:00:00Z
2002-07-20T15:30:00Z
2002-12-31T23:59:59Z

Falsches Format (Monat/Tag/Jahr) kann nicht korrekt sortiert werden:
01/15/2002 10:00:00
12/31/2002 23:59:59  ← String-Sortierung platziert dies vor Juli
07/20/2002 15:30:00

5.2. Human Readability (Menschliche Lesbarkeit)​

Menschliche Lesbarkeit hat sich als wertvolles Merkmal von Internetprotokollen erwiesen. Menschlich lesbare Protokolle reduzieren die Debugging-Kosten erheblich, da telnet oft als Testclient ausreicht und Netzwerkanalysatoren nicht mit Protokollkenntnissen modifiziert werden müssen. Andererseits führt menschliche Lesbarkeit manchmal zu Interoperabilitätsproblemen.

Problembeispiele:

❌ "10/11/1996" ist für den globalen Austausch völlig ungeeignet
   USA: 11. Oktober 1996
   Europa: 10. November 1996
   
❌ Übersetzung von Monatsabkürzungen
   Englisch: "Jan", "Feb", "Mar"
   Französisch: "Jan", "Fév", "Mar"  ← Beeinträchtigt Interoperabilität

Da kein Datums- und Zeitformat nach den Konventionen aller Länder lesbar ist, sollten Internetclients darauf vorbereitet sein (SHOULD), Daten in ein für die Lokalität geeignetes Anzeigeformat zu transformieren. Dies kann die Umwandlung von UTC in Ortszeit einschließen.

5.3. Rarely Used Options (Selten verwendete Optionen)​

Ein Format, das selten verwendete Optionen enthält, verursacht wahrscheinlich Interoperabilitätsprobleme. Dies liegt daran, dass selten verwendete Optionen weniger wahrscheinlich in Alpha- oder Beta-Tests verwendet werden, sodass Fehler beim Parsing weniger wahrscheinlich entdeckt werden. Selten verwendete Optionen sollten wann immer möglich obligatorisch gemacht oder weggelassen werden, um der Interoperabilität willen.

Das unten definierte Format enthält nur eine selten verwendete Option: Sekundenbruchteile (Fractions of a Second). Es wird erwartet, dass dies nur von Anwendungen verwendet wird, die eine strikte Sortierung von Datums-/Zeitstempeln erfordern oder ungewöhnliche Präzisionsanforderungen haben.

5.4. Redundant Information (Redundante Informationen)​

Wenn ein Datums-/Zeitformat redundante Informationen enthält, führt es die Möglichkeit ein, dass die redundanten Informationen nicht korrelieren. Zum Beispiel führt das Einbeziehen des Wochentags in ein Datums-/Zeitformat die Möglichkeit ein, dass der Wochentag falsch ist, aber das Datum korrekt ist, oder umgekehrt. Da es nicht schwierig ist, den Wochentag aus dem Datum zu berechnen (siehe Anhang B), sollte der Wochentag nicht in ein Datums-/Zeitformat aufgenommen werden.

Problembeispiel:

❌ "Monday, 2002-07-16T10:00:00Z"
   Problem: 16. Juli 2002 ist tatsächlich ein Dienstag, nicht ein Montag
   Wenn Tag und Datum nicht übereinstimmen, welchem sollte vertraut werden?

✅ "2002-07-16T10:00:00Z"
   Lösung: Wochentag weglassen, bei Bedarf berechnen

5.5. Simplicity (Einfachheit)​

Der vollständige Satz von Datums- und Zeitformaten, der in ISO 8601 [ISO8601] spezifiziert ist, ist ziemlich komplex in dem Versuch, mehrere Darstellungen und Teildarstellungen bereitzustellen. Anhang A enthält einen Versuch, die vollständige Syntax von ISO 8601 in ABNF zu übersetzen. Internetprotokolle haben etwas andere Anforderungen, und Einfachheit hat sich als wichtiges Merkmal erwiesen. Darüber hinaus benötigen Internetprotokolle normalerweise eine vollständige Datenspezifikation, um echte Interoperabilität zu erreichen. Daher wird die vollständige Syntax von ISO 8601 für die meisten Internetprotokolle als zu komplex angesehen.

Der folgende Abschnitt definiert ein Profil von ISO 8601 für die Verwendung im Internet. Es ist eine konsistente Teilmenge des erweiterten ISO 8601-Formats. Einfachheit wird erreicht, indem die meisten Felder und Interpunktionen obligatorisch gemacht werden.

5.6. Internet Date/Time Format (Internet-Datums-/Zeitformat)​

Das folgende Profil von ISO 8601 [ISO8601]-Daten sollte (SHOULD) in neuen Protokollen im Internet verwendet werden. Dies wird unter Verwendung der in [ABNF] definierten Syntaxbeschreibungsnotation spezifiziert.

ABNF-Syntaxdefinition​

date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

Wichtige Hinweise​

Groß-/Kleinschreibung: Gemäß [ABNF] und ISO8601 können die Zeichen "T" und "Z" in dieser Syntax alternativ auch als Kleinbuchstaben "t" bzw. "z" verwendet werden.

Spezifikationen, die dieses Format in Umgebungen verwenden, in denen Groß-/Kleinschreibung signifikant ist (wie XML), können (MAY) die Datums-/Zeitsyntax weiter einschränken, sodass die in der Datums-/Zeitsyntax verwendeten Buchstaben 'T' und 'Z' immer großgeschrieben sein müssen. Anwendungen, die dieses Format generieren, sollten (SHOULD) Großbuchstaben verwenden.

Trennzeichen: ISO 8601 definiert Datum und Zeit getrennt durch "T". Anwendungen, die diese Syntax verwenden, können (MAY) aus Gründen der Lesbarkeit wählen, ein full-date und full-time getrennt durch (zum Beispiel) ein Leerzeichen anzugeben.

Formatbeispiele​

Standardformat:
2002-07-15T10:30:00Z
2002-07-15T10:30:00.123Z
2002-07-15T10:30:00+08:00
2002-07-15T10:30:00-04:00

Mit Sekundenbruchteilen:
2002-07-15T10:30:00.123456Z
2002-07-15T10:30:00.52Z

Lesbare Varianten (nicht standardmäßig, aber erlaubt):
2002-07-15 10:30:00Z
2002-07-15t10:30:00z

5.7. Restrictions (Einschränkungen)​

Das Grammatikelement date-mday repräsentiert die Tagesnummer innerhalb des aktuellen Monats. Der Maximalwert variiert basierend auf Monat und Jahr:

MonatsnummerMonat/JahrMaximales date-mday
01Januar (January)31
02Februar, normal (February, normal)28
02Februar, Schaltjahr (February, leap year)29
03März (March)31
04April30
05Mai (May)31
06Juni (June)30
07Juli (July)31
08August31
09September30
10Oktober (October)31
11November30
12Dezember (December)31

Schaltsekunden​

Das Grammatikelement time-second kann (MAY) am Ende von Monaten, in denen eine Schaltsekunde auftritt, den Wert "60" haben. Schaltsekunden werden verwendet, um UTC nahe an der Rotationszeit der Erde zu halten. Siehe Anhang D für weitere Informationen über Schaltsekunden.

Schaltsekundenbeispiele:

1990-12-31T23:59:60Z  ✅ Gültig (Schaltsekunde am 31. Dezember 1990)
1990-12-31T23:59:61Z  ❌ Ungültig (Maximum ist 60)
1990-06-15T23:59:60Z  ❌ Ungültig (Schaltsekunden nur am Monatsende)

5.8. Examples (Beispiele)​

Hier sind einige Beispiele für gültige RFC 3339-Datums-/Zeitstempel:

1985-04-12T23:20:50.52Z
  Darstellt: 12. April 1985, 23:20:50.52 UTC

1996-12-19T16:39:57-08:00
  Darstellt: 19. Dezember 1996, 16:39:57 Pacific Standard Time (PST)
  Äquivalentes UTC: 1996-12-20T00:39:57Z

1990-12-31T23:59:60Z
  Darstellt: Schaltsekunde am 31. Dezember 1990

1990-12-31T15:59:60-08:00
  Darstellt: Schaltsekunde am 31. Dezember 1990 in PST
  Äquivalentes UTC: 1990-12-31T23:59:60Z

1937-01-01T12:00:27.87+00:20
  Darstellt: 1. Januar 1937, 12:00:27.87, UTC+00:20
  (Historisches Zeitzonenbeispiel)

Ungültige Beispiele​

❌ 1985-04-12  (fehlende Zeit)
❌ 23:20:50.52Z  (fehlendes Datum)
❌ 1985-04-12 23:20:50.52Z  (sollte 'T' nicht Leerzeichen verwenden, obwohl einige Implementierungen es erlauben)
❌ 1985-04-32T23:20:50.52Z  (ungültiges Datum: April hat keinen 32. Tag)
❌ 1985-02-29T23:20:50.52Z  (ungültiges Datum: 1985 ist kein Schaltjahr)

Implementierungsempfehlung: Immer das Standardformat generieren (unter Verwendung des 'T'-Trennzeichens und des Großbuchstabens 'Z'), aber liberal parsen (akzeptiere 't', 'z' und möglicherweise Leerzeichen-Trennzeichen).

Letztes Update am