Ein Datum als ISO 8601 schreiben — und warum nur dieses Format eindeutig ist

01/02/2026 und die sechs Sprachen, in denen diese Website geschrieben ist

Wer in Paris, Madrid, Lissabon, Berlin oder Rom liest, versteht 01/02/2026 als den ersten Februar. Wer in den Vereinigten Staaten liest, versteht dieselben acht Ziffern als den zweiten Januar. Nichts in der Zeichenkette entscheidet: Beide Lesarten sind vollständig, beide sind üblich, und beide liegen etwa in der Hälfte der Fälle daneben, sobald die Zeichenkette gereist ist.

Der Fehler ist leise, und genau das macht ihn teuer. Ein Formular nimmt das Datum an, eine Datenbank speichert es, ein Bericht druckt es, und nichts widerspricht bis zum zwölften des Monats, wenn die beiden Lesarten nicht mehr beide ein gültiges Datum ergeben und eine schließlich einen Fehler wirft. Alles zwischen dem ersten und dem zwölften wurde stillschweigend verschoben. Eine für den 3. April geplante Lieferung kommt am 4. März, eine Rechnung trägt ein elf Monate zu frühes Datum, und die Prüfspur verzeichnet beide als völlig gewöhnliche Buchungen.

2026-02-01 hat keine zweite Lesart. Das Jahr steht zuerst, weil es die größte Einheit ist, der Monat als zweites, der Tag zuletzt, und jedes ist auf eine feste Breite aufgefüllt. Keine Locale zu befragen, keine Trennzeichen-Konvention zu erraten, kein Monat, der als Tag durchgehen könnte. Das ist der ganze Beitrag der Norm, und er genügt.

Als Text sortieren und nach Zeit sortieren ist dieselbe Handlung

Ordne die Felder von groß nach klein, fülle jedes auf feste Breite, und der lexikografische Vergleich wird gratis zum chronologischen. Fünf Zeitpunkte liefen durch das Werkzeug, einmal als Zeichenketten und einmal nach ihren Unix-Zeitstempeln sortiert: Beide Reihenfolgen waren gleich. Diese Eigenschaft ist der Grund, warum ein Ordner mit Dateien namens 2026-02-01-notizen.md, 2026-02-11-notizen.md und 2026-10-02-notizen.md in jedem Dateimanager, jeder Shell und jeder Sicherungsliste richtig sortiert liegt — ganz ohne Datumsauswertung.

Die Eigenschaft hat eine Bedingung, die leicht verlorengeht: Jede Zeichenkette muss denselben Versatz tragen. Zwei Zeitpunkte zeigen es. 2026-01-05T09:00:00Z und 2026-01-05T10:00:00+02:00 sortieren als Text in dieser Reihenfolge, weil das Zeichen 9 vor dem Zeichen 1 gefolgt von 0 kommt. Ihre Unix-Zeitstempel sind 1767603600 und 1767600000, der zweite geschah also früher. Die Textreihenfolge ist falsch, und nichts meldet es. Kann eine Spalte gemischte Versätze enthalten, normalisiere vor dem Sortieren alles auf Z, oder sortiere nach dem Zeitstempel.

Dieselbe Überlegung erklärt die Dateinamens-Konvention. Setze das Datum an den Anfang des Namens, und der Ordner sortiert sich von selbst; setze es ans Ende, und er sortiert nach dem, was davorsteht. Nimm Bindestriche statt Schrägstriche, denn der Schrägstrich ist auf jedem System ein Pfadtrenner, und Doppelpunkte — in einer Uhrzeit zulässig, in einem Dateinamen unter Windows verboten — sind der Grund, warum ein zeitgestempelter Name meist auf 2026-02-01T093000Z zurückfällt, das Basisformat, das die Norm ebenfalls definiert.

Das T, das Z und ein Versatz, der keine Zeitzone ist

Das große T verbindet Datum und Uhrzeit. Es steht dort, weil Datum und Uhrzeit zwei getrennte Darstellungen sind und irgendetwas sagen muss, wo die eine endet und die andere beginnt; für einen Menschen täte es ein Leerzeichen, und genau das druckt eine Datenbank, aber die strenge Norm will das T. Das abschließende Z bedeutet Versatz null — Zulu, aus dem militärischen Buchstabieralphabet — und ist mit +00:00 austauschbar.

Ein Versatz wie +02:00 sagt, wie weit die Wanduhr in diesem Augenblick von UTC entfernt ist, und sonst nichts. Er benennt nicht Paris: Er ist im selben Moment auch Kairo, Johannesburg, Helsinki und das halbe Europa, und dieselbe Pariser Uhr steht im Januar auf +01:00. Deshalb muss ein künftiger Termin als Zonenkennung — Europe/Paris — mit der lokalen Uhrzeit gespeichert werden und nicht als Versatz. Speichere 2027-03-28T10:00:00+01:00 für eine Besprechung, und sie liegt nach der Zeitumstellung um neun Uhr morgens, was niemand vereinbart hat.

Ein Datum-Zeit-Wert ganz ohne Versatz ist ein lokales Datum, und seine Bedeutung ist die, die die Maschine des Lesenden festlegt. Das ist gültiges ISO 8601 und gelegentlich genau das Gewünschte — ein Laden öffnet um 09:00 in der Stadt, in der er steht —, aber es ist kein Zeitpunkt, und ihn dafür zu halten ist der Weg, auf dem eine Logzeile von einem Server in Übersee zur falschen Stunde eintrifft und ein Geburtsdatum in einer Datenbank für alle westlich des Meridians zum Vortag wird.

Auf der Jagd nach dem Mitternachts-Tagesfehler — der nicht existiert

Der häufigste echte Fehler in Datumswerkzeugen ist eine Umrechnung, die über die lokale Zeitzone des Browsers läuft und nahe Mitternacht einen Tag danebenliegt. Dieses hat ihn nicht, aus einem baulichen Grund: Es rührt lokale Zeit nie an. Ein Zeitpunkt wird als sieben ganze Zahlen gehalten — Jahr, Monat, Tag, Stunde, Minute, Sekunde und Versatz in Minuten — und die Umrechnung nach UTC verschiebt die Tagesnummer mit Ganzzahlarithmetik, statt ein Date zu bauen. Der Jetzt-Knopf liest die Uhr über getUTCFullYear und Geschwister und setzt den Versatz auf UTC+00:00.

Die Grenzfälle wurden absichtlich durchgespielt. Paris um 00:30 am 13. August mit Versatz +02:00 ergibt die UTC-Form 2026-08-12T22:30:00Z und ein HTTP-Datum von Wed, 12 Aug 2026 22:30:00 GMT — einen Tag früher, was richtig ist, denn es ist derselbe Zeitpunkt. New York um 23:30 am 12. August mit Versatz −04:00 geht in die andere Richtung, auf 2026-08-13T03:30:00Z. Die Chatham-Inseln um 00:10 am 1. Januar mit Versatz +12:45 kommen als 2025-12-31T11:25:00Z heraus und überschreiten Tag und Jahr zugleich. Fünf dieser Fälle wurden gegen Date.UTC geprüft, darunter das vor der Epoche liegende 1969-07-20T20:17:40Z, dessen Zeitstempel von −14 182 940 exakt übereinstimmte.

Das Einzige, was nach einem Tagesfehler aussieht, ist der Jetzt-Knopf, und darin zeigt sich eine bewusste Entscheidung. Weil die Uhr in UTC gelesen wird, sieht ein Pariser Leser, der ihn am 13. August um halb eins nachts drückt, das Datumsfeld mit dem 12. August und die Zeit mit 22:30 vorbelegt. Das ist derselbe Augenblick, ausgedrückt in der Zone, die das Werkzeug voreinstellt, nicht das Datum von gestern. Willst du deine eigene Wanduhr, trage Datum und Zeit von Hand ein und wähle deinen Versatz aus der Liste.

RFC 3339 ist gemeint, wenn eine API ISO sagt — und sie ist enger

Wenn eine API sagt, sie wolle ISO 8601, will sie fast immer RFC 3339, die sich selbst als Profil von ISO 8601 für den Gebrauch im Internet beschreibt. Ein Profil ist eine Teilmenge: Alles, was RFC 3339 annimmt, ist ISO 8601, und ein großer Teil von ISO 8601 ist kein RFC 3339. Ihre Grammatik verlangt ein vollständiges Datum, dann ein T, dann eine vollständige Zeit, dann einen Versatz — nichts darf fehlen.

Vier Unterschiede zählen in der Praxis, alle in der Grammatik der RFC nachlesbar. Ihre Stunde ist als zwei Ziffern von 00 bis 23 definiert, also ist 24:00 — ein zulässiges ISO-Tagesende, das denselben Zeitpunkt bezeichnet wie Mitternacht am nächsten Morgen — kein RFC 3339. Ihr Versatz schreibt sich als Vorzeichen, zwei Ziffern, Doppelpunkt, zwei Ziffern, also sind +0200 und +02 ISO 8601 und keines davon RFC 3339. Sie kennt weder Wochen- noch Ordinaldaten, 2026-W33-4 und 2026-225 fallen also heraus. Und ein bloßes Datum wie 2026-08-13, oder ein Jahr mit Monat, oder ein Jahr allein, ist nach RFC 3339 überhaupt kein Datum-Zeit-Wert.

Zwei Feinheiten gehen in die andere Richtung, wo RFC 3339 großzügiger ist. Sie gibt −00:00 eine eigene Bedeutung: Die UTC-Zeit ist bekannt, der lokale Versatz nicht — bewusst verschieden von Z oder +00:00. Und eine Anmerkung im selben Abschnitt sagt, Anwendungen dürften der Lesbarkeit halber ein Leerzeichen statt des T verwenden, und genau das drucken Datenbanken. Das Werkzeug nimmt ein eingefügtes Leerzeichen an und sagt dir, dass es eines gesehen hat; es nimmt auch −00:00 an und macht daraus stillschweigend ein Z, sodass die von der RFC gezogene Unterscheidung einen Hin- und Rückweg nicht übersteht.

Eine Folge gehört benannt, weil das Werkzeug es nicht tut. Sein Hauptausgabefeld, das als erweiterte Datum-und-Zeit-Form beschriftete, ist RFC 3339, solange die Stunde zwischen 00 und 23 liegt — und es ist es nicht, wenn die Stunde 24 beträgt, was der Parser annimmt. Füge 2026-08-13T24:00:00Z ein, und dieses Feld gibt es unverändert zurück, und das als E-Mail-Datum beschriftete Feld druckt eine Stunde, die RFC 5322 ebenfalls nicht erlaubt. Die UTC-Zeile daneben stimmt: Sie zeigt 2026-08-14T00:00:00Z. Kopierst du einen Wert in eine API, kopiere diesen.

Wochendaten, Ordinaldaten und die Kleinigkeiten, die das Werkzeug falsch macht

ISO 8601 definiert zwei weitere Datumsformen, und das Werkzeug druckt beide. Ein Wochendatum nennt Jahr, Woche und Wochentag, und sein Jahr ist nicht immer das Kalenderjahr: Eine Woche gehört zu dem Jahr, in dem ihr Donnerstag liegt. Schicke den 1. Januar 2027 hindurch, und er kommt als 2026-W53-5 zurück; schicke den 31. Dezember 2024, und er kommt als 2025-W01-2 zurück. Beides wurde geprüft. Ein Ordinaldatum nennt das Jahr und den Tag darin, der 13. August 2026 ist also 2026-225. Beide sortieren lexikografisch ebenso gut wie Kalenderdaten — mische aber nie drei Formen in einer Spalte, denn 2026-W33-4 und 2026-08-13 sortieren gegeneinander als Zeichenketten ohne jeden Bezug zur Zeit.

Drei kleine Mängel kamen beim Testen zum Vorschein; sie gehören gekannt, nicht gefürchtet. Eine Sekunde von 60 wird überall angenommen — füge 2026-08-13T00:30:60Z ein, und das Werkzeug nimmt sie und berechnet einen Unix-Zeitstempel von 1786581060, also 00:31:00 —, während Norm wie RFC die 60 nur unter Schaltsekunden-Regeln zulassen. Bruchteile von Sekunden werden gelesen und dann weggeworfen: 2026-08-13T00:30:00.123Z kommt als 2026-08-13T00:30:00Z zurück, ohne Hinweis darauf, dass die Millisekunden fort sind. Und der Dauer-Parser weist P0D zurück, eine zulässige Nulldauer, weil er jede Dauer verwirft, deren Felder alle null sind.

Was es gut macht, verdient denselben Satz. Es weist 2026-02-30 und 2026-08-13T25:00:00Z zurück, weist ein nicht aufgefülltes 2026-8-3 zurück und weist 13/08/2026 und 08/13/2026 rundheraus zurück, was für ein Werkzeug, dessen Aufgabe es ist zu sagen, was ISO 8601 ist und was nicht, die richtige Antwort ist. Es liest das Basisformat 20260813T003000+0200, liest ein kleines t und z und sagt dir, welche der drei Datumsformen es erkannt hat. Auch Dauern werden richtig gelesen, samt dem Dezimalkomma von P1,5D, das es zu P1.5D normalisiert.

Häufige Fragen

Soll ich den Versatz schreiben oder überall Z verwenden?

Für alles, was du speicherst, protokollierst oder zwischen Maschinen verschickst, normalisiere auf Z. Jeder Wert trägt dann denselben Versatz, Textsortierung entspricht Zeitsortierung, Vergleiche brauchen keine Umrechnung, und es gibt nichts falsch zu machen. Behalte den lokalen Versatz nur, wenn die lokale Lesart selbst die Tatsache ist — ein Beleg, der sagen soll, dass die Zahlung um 09:15 am Morgen des Ladens erfolgte, eine für Fahrgäste gedruckte Zugabfahrt. Und für einen künftigen Termin taugt keines von beiden: Speichere die Zonenkennung und die lokale Uhrzeit, denn welchen Versatz diese Zone an jenem Tag haben wird, hat noch niemand entschieden.

Sind ISO 8601 und RFC 3339 dasselbe?

Nein. RFC 3339 bezeichnet sich selbst als Profil von ISO 8601 für Internet-Protokolle, und ein Profil ist eine Teilmenge. Ihre Grammatik lässt nur das Kalenderdatum zu, verlangt Zeit und Versatz, beschränkt die Stunde auf 00 bis 23 und schreibt den Versatz mit verbindlichem Doppelpunkt und Minuten. Ein bloßes Datum, ein Wochendatum wie 2026-W33-4, ein Ordinaldatum wie 2026-225, das Basisformat ohne Bindestriche, eine Stunde von 24 und ein Versatz als +0200 oder +02 sind also alle gültiges ISO 8601 und keines gültiges RFC 3339. In der Gegenrichtung gibt RFC 3339 dem -00:00 eine eigene Bedeutung — die UTC-Zeit ist bekannt, der lokale Versatz nicht — und erlaubt kleines t und z. Verlangt eine API ISO 8601, schicke RFC 3339, und du genügst beiden.

Warum zeigt das Werkzeug beim Klick auf Jetzt das Datum von gestern?

Weil es die Uhr in UTC liest und den Versatz auf UTC+00:00 setzt, nicht weil es sich verzählt hätte. Bist du östlich von Greenwich und ist es kurz nach Mitternacht, steht deine Wanduhr schon im neuen Tag, während UTC noch im alten ist. Ein Pariser Leser, der um 00:30 am 13. August auf Jetzt klickt, sieht 12. August und 22:30 eingetragen — denselben Augenblick, ausgedrückt in der voreingestellten Zone des Werkzeugs. Nichts an der Umrechnung läuft über die Zeitzone deiner Maschine: Der Zeitpunkt wird als ganze Zahlen gehalten und mit Ganzzahlarithmetik verschoben, und fünf Grenzfälle, darunter ein Datum vor der Epoche und ein Versatz von +12:45, stimmten exakt mit Date.UTC überein. Willst du deine Wanduhrzeit, tippe Datum und Zeit ein und wähle deinen Versatz aus der Liste.

Kann ich Daten wirklich durch Sortieren des Textes sortieren?

Ja, unter einer Bedingung: Jede Zeichenkette muss dieselbe Form und denselben Versatz haben. Fünf Zeitpunkte wurden im Werkzeug auf beide Weisen sortiert, und die Reihenfolgen waren gleich. Bricht die Bedingung, scheitert es stillschweigend: 2026-01-05T09:00:00Z sortiert als Text vor 2026-01-05T10:00:00+02:00, doch ihre Zeitstempel sind 1767603600 und 1767600000 — der zweitsortierte geschah zuerst. Kalenderdaten mit Wochendaten zu mischen bricht es ebenso, denn 2026-W33-4 vergleicht sich mit 2026-08-13 als zwei Zeichenketten ohne gemeinsame Bedeutung. Normalisiere vor dem Sortieren auf Z und auf eine Form, dann ist der Kniff völlig sicher — genau deshalb ist er die richtige Art, Dateien zu benennen.

Warum schreibt sich der 1. Januar 2027 als 2026-W53-5?

Weil eine Woche ganz zu einem Jahr gehört und die Norm sie dem Jahr gibt, in dem ihr Donnerstag liegt. Die Woche mit dem 1. Januar 2027 hat ihren Donnerstag am 31. Dezember 2026, die ganze Woche ist also Woche 53 des Wochenjahres 2026, und der darin enthaltene Freitag ist Tag 5. Dieselbe Regel wirkt umgekehrt: Der 31. Dezember 2024 kommt als 2025-W01-2 heraus, beides im Werkzeug geprüft. Zwei praktische Folgen. Das Wochenjahr ist nicht das Kalenderjahr und darf in einer Berichtsüberschrift nie an einen Kalendermonat gehängt werden. Und ein Jahr hat 53 Wochen, wenn sein 1. Januar ein Donnerstag ist oder ein Mittwoch in einem Schaltjahr — 2026 hat 53, 2027 hat 52 —, sodass ein Diagramm mit festen 52 Spalten etwa alle fünf bis sechs Jahre eine Woche verrutschen lässt.