ISO 8601

Der Standard definiert nicht die Zeit selbst. Er beschreibt, wie Datums- und Zeitangaben strukturiert, gespeichert, übertragen und verarbeitet werden können.

Besonders in Informationsmanagementsystemen, Datenbanken, Schnittstellen, Archivlösungen und digitalen Workflows sind eindeutige Zeitangaben entscheidend. Schon kleine Missverständnisse können zu falschen Fristen, fehlerhaften Auswertungen, inkonsistenten Protokollen oder unvollständigen Nachweisen führen.

In der Praxis ist ISO 8601 besonders wertvoll, wenn Informationen zwischen mehreren Systemen, Standorten, Abteilungen oder Ländern ausgetauscht werden. Ein einheitliches Darstellungsformat stellt sicher, dass Dokumentstatus, Freigabezeitpunkte, Audit-Ereignisse oder Archivierungsfristen konsistent interpretiert werden.

Was bedeutet ISO 8601?

ISO 8601 ist eine Norm der International Organization for Standardization. ISO ist der offizielle Kurzname der Organisation, kein Akronym der englischen Bezeichnung.

Die Norm definiert strukturierte Schreibweisen für Datums- und Zeitangaben. Ein häufig verwendetes ISO-8601-Datum sieht so aus:

2026-04-28

Diese Form steht für das Kalenderdatum 28. April 2026. Die Reihenfolge ist Jahr, Monat, Tag.

Genauer handelt es sich um das erweiterte Kalenderdatumsformat. Das Basisformat ohne Trennzeichen ist ebenfalls normkonform:

20260428

ISO 8601 umfasst jedoch mehr als diese Schreibweise. Der Standard kennt auch Kalenderwochendaten, Ordinaldaten, reduzierte Genauigkeiten und Zeitintervalle.

Beispiele sind:

2026-W18-2
2026-118
2026-04

2026-W18-2 bezeichnet Dienstag in Kalenderwoche 18. 2026-118 bezeichnet den 118. Tag des Jahres 2026.

ISO 8601 basiert grundsätzlich auf dem gregorianischen Kalender. Für frühere historische Daten wird häufig der proleptische gregorianische Kalender verwendet.

Das bedeutet: Der gregorianische Kalender wird rechnerisch auf Zeiträume angewendet, in denen er historisch noch nicht überall galt.

Die aktuelle Normstruktur unterscheidet insbesondere ISO 8601-1 für Grundregeln und ISO 8601-2 für Erweiterungen und zusätzliche Ausdrucksformen.

Warum ist ISO 8601 wichtig?

ISO 8601 ist wichtig, wenn Daten automatisiert verarbeitet, sortiert, synchronisiert oder nachvollziehbar dokumentiert werden.

Das betrifft Systeme, in denen Zeitangaben nicht nur angezeigt, sondern als Grundlage für Entscheidungen, Workflows oder Nachweise verwendet werden.

Dazu gehören zum Beispiel:

• Dokumentenmanagementsysteme
• Enterprise-Content-Management-Systeme
• Enterprise-Resource-Planning-Systeme
• Customer-Relationship-Management-Systeme
• Datenbanken
• Schnittstellen und APIs
• Archivsysteme
• Berichtswesen und Analytics
• Logdateien
• Workflow- und Ticketsysteme
• Vertragsmanagementsysteme
• Qualitätsmanagementsysteme
• E-Mail-Archivierung und Records Management

Wenn unterschiedliche Systeme Datumswerte verschieden interpretieren, entstehen schnell falsche Sortierungen, fehlerhafte Fristen oder widersprüchliche Auswertungen.

In einem Informationsmanagementsystem kann das bedeuten, dass ein Dokument zu früh archiviert oder ein Vertrag falsch verlängert wird.

Ein einfaches Beispiel zeigt das Risiko:

03/04/2026

Diese Angabe kann je nach Land den 3. April oder den 4. März bedeuten.

Die ISO-8601-Schreibweise ist dagegen eindeutig:

2026-04-03

Gerade bei internationalen Organisationen, Cloud-Diensten und verteilten Teams ist diese Eindeutigkeit entscheidend.

Grundformen von ISO 8601

ISO 8601 unterscheidet verschiedene Darstellungsformen. In technischen Systemen begegnen Ihnen vor allem Kalenderdaten, Uhrzeiten, kombinierte Angaben, Dauern und Intervalle.

Eine kompakte Übersicht:

BedeutungBeispielHinweisKalenderdatum, erweitert2026-04-28Jahr, Monat, TagKalenderdatum, Basisformat20260428ohne TrennzeichenUhrzeit, erweitert14:30:00Stunde, Minute, SekundeUhrzeit, Basisformat143000ohne TrennzeichenDatum und Uhrzeit ohne Offset2026-04-28T14:30:00lokal oder kontextabhängigUTC-Zeitpunkt2026-04-28T14:30:00ZZ steht für UTCZeitpunkt mit UTC-Offset2026-04-28T16:30:00+02:00lokale Zeit ist UTC plus zwei StundenDauerP3Ddrei KalendertageIntervall2026-04-01/2026-05-01Zeitraum von Start bis EndeKalenderwoche2026-W18Kalenderwoche 18WiederholungsintervallR5/P1DInterpretation muss dokumentiert werden

Wichtig ist: Viele Systeme unterstützen nur eine Teilmenge von ISO 8601. Deshalb sollten Sie das konkret erlaubte Format dokumentieren.

Aufbau eines Kalenderdatums

Das erweiterte Kalenderdatumsformat wird häufig so erklärt:

YYYY-MM-DD

Dabei handelt es sich um ein erklärendes Strukturmuster, nicht um einen universellen Formatstring für jede Programmiersprache oder Bibliothek.

In diesem Muster steht:

• YYYY für das Jahr mit vier Ziffern
• MM für den Monat mit zwei Ziffern
• DD für den Tag mit zwei Ziffern

Beispiel:

2026-04-28

Diese Darstellung ist gut lesbar und international eindeutig. Sie unterscheidet sich von regionalen Schreibweisen wie 28.04.2026 oder 04/28/2026.

Das Basisformat ohne Trennzeichen lautet:

20260428

Beide Formen können ISO-8601-konform sein. In fachlichen Dokumentationen und APIs wird häufig das erweiterte Format bevorzugt.

Wichtig sind führende Nullen. 2026-04-08 ist konsistent, während 2026-4-8 in vielen Systemen Validierungsprobleme verursacht.

Bei vollständigen Kalenderdaten im gleichen Format funktioniert lexikografische Sortierung zuverlässig. Alphabetische Reihenfolge entspricht dann der chronologischen Reihenfolge.

Beispiel:

2026-04-28_protokoll.pdf
2026-04-29_protokoll.pdf
2026-05-02_protokoll.pdf

Diese Eigenschaft gilt jedoch nicht automatisch für alle ISO-8601-Varianten oder Zeitstempel mit unterschiedlichen UTC-Offsets.

Vor einer chronologischen Sortierung sollten Zeitpunkte mit unterschiedlichen Offsets auf eine gemeinsame Zeitbasis normalisiert werden, häufig auf UTC.

Uhrzeit nach ISO 8601

Eine Uhrzeit im erweiterten Format lautet:

HH:MM:SS

Beispiel:

14:30:00

Dabei steht:

• HH für die Stunde
• MM für die Minute
• SS für die Sekunde

ISO 8601 verwendet das 24-Stunden-Format. Dadurch entfallen Zusätze wie AM oder PM.

Weitere Beispiele:

09:05:30
23:59:59
00:00:00

Das Basisformat ohne Trennzeichen lautet:

143000

Zeitangaben können auch mit reduzierter Genauigkeit vorkommen, sofern das verwendete Profil dies erlaubt:

14:30
14

Wenn höhere Genauigkeit erforderlich ist, können Sekundenbruchteile angegeben werden:

2026-04-28T14:30:00.250Z

Viele technische Profile verwenden den Punkt als Dezimaltrennzeichen. ISO 8601 kann je nach Kontext auch ein Komma vorsehen.

Schaltsekunden können als 23:59:60 dargestellt werden, aber nur bei tatsächlichen positiven Schaltsekunden.

Viele Datenbanken, Programmiersprachen und APIs akzeptieren 23:59:60 trotz ISO-8601-Nähe nicht.

Auch 24:00:00 ist versions- und profilabhängig. ISO 8601:2004 erlaubte diese Darstellung für das Tagesende.

ISO 8601-1:2019 ließ 24:00:00 zunächst nicht zu. Durch Amendment 1:2022 wurde diese Form wieder zugelassen.

Prüfen Sie deshalb immer, ob Ihre Zielsysteme 24:00:00 akzeptieren oder nur 00:00:00 des Folgetags unterstützen.

Kombination aus Datum und Uhrzeit

In digitalen Prozessen reicht ein reines Datum oft nicht aus. Für Uploads, Freigaben, Änderungen oder Protokolle benötigen Sie genaue Zeitangaben.

Datum und Uhrzeit werden mit einem T verbunden:

2026-04-28T14:30:00

Das T kennzeichnet den Beginn der Uhrzeitangabe. Diese Form ist in APIs, Datenbanken, JSON-Dokumenten und Logdateien weit verbreitet.

Ohne UTC-Offset oder Z ist diese Angabe lokal oder kontextabhängig. Sie beschreibt nicht zwingend einen global eindeutigen Zeitpunkt.

Für globale Ereignisse ist deshalb eine Angabe mit UTC oder UTC-Offset zuverlässiger:

2026-04-28T14:30:00Z
2026-04-28T16:30:00+02:00

Für reine Anzeigezwecke kann ein System daraus ein lokales Format erzeugen, etwa:

28.04.2026, 16:30 Uhr

Für Speicherung, Integration und Datenübertragung ist eine klar dokumentierte ISO-8601-Form meist zuverlässiger.

UTC-Offset, UTC und Zeitzone

ISO 8601 kann UTC und UTC-Offsets darstellen. Es bildet jedoch keine benannten Zeitzonen wie Europe/Berlin oder America/New_York ab.

Eine UTC-Angabe sieht so aus:

2026-04-28T14:30:00Z

Das Z steht für UTC, die koordinierte Weltzeit. Es wird auch als Zulu-Zeit bezeichnet.

Alternativ kann ein UTC-Offset angegeben werden:

2026-04-28T16:30:00+02:00

Das bedeutet: Die lokale Zeit ist UTC plus zwei Stunden. Zur Umrechnung nach UTC werden zwei Stunden abgezogen.

Derselbe Zeitpunkt ist:

2026-04-28T14:30:00Z

Typische Offset-Angaben sind:

• Z für UTC
• +01:00 für lokale Zeit gleich UTC plus eine Stunde
• +02:00 für lokale Zeit gleich UTC plus zwei Stunden
• -05:00 für lokale Zeit gleich UTC minus fünf Stunden
• -08:00 für lokale Zeit gleich UTC minus acht Stunden

Für Deutschland gilt häufig +01:00 im Winter und +02:00 im Sommer. Der Offset allein ist aber keine vollständige Zeitzone.

Eine benannte Zeitzone enthält zusätzlich Regeln für Sommerzeit, historische Änderungen und mögliche zukünftige Anpassungen.

Für technische Ereignisse ist UTC oft ideal. Für zukünftige lokale Termine kann zusätzlich eine benannte Zeitzone erforderlich sein.

Beispiel für eine system- oder API-spezifische Datenstruktur:

{
 "localDateTime": "2026-10-27T09:00:00",
 "timeZone": "Europe/Berlin"
}

Die Kombination aus lokalem Datum, lokaler Uhrzeit und IANA-Zeitzone ist als Gesamtstruktur keine reine ISO-8601-Schreibweise.

Sie ist aber in Kalender-, Workflow- und Terminplanungssystemen oft fachlich notwendig.

Floating Time: lokale Zeiten ohne Offset

Manche Zeitangaben sind bewusst lokal und haben keinen UTC-Offset. Solche Angaben werden häufig als Floating Time bezeichnet.

Ein Beispiel ist ein wiederkehrender Termin:

09:00:00

Fachlich kann das bedeuten: Jeden Tag um 09:00 Uhr in der jeweils relevanten lokalen Zeitzone.

Floating Time eignet sich für lokale Termine, Öffnungszeiten oder wiederkehrende Aufgaben. Sie eignet sich weniger für globale Ereignisprotokolle.

Wenn ein Audit-Log einen tatsächlichen Zugriff dokumentiert, sollte der Zeitpunkt eindeutig sein, etwa mit UTC:

2026-04-28T07:00:00Z

Wenn ein Workflow jeden Morgen lokal starten soll, kann eine lokale Uhrzeit mit zusätzlicher Zeitzonenregel sinnvoller sein.

Kalenderwochen und Ordinaldaten

ISO 8601 definiert auch Kalenderwochendaten. Eine Kalenderwoche wird mit W angegeben:

2026-W18

Das steht für die 18. Kalenderwoche im Jahr 2026.

Ein konkreter Tag innerhalb der Kalenderwoche kann ergänzt werden:

2026-W18-2

Das bedeutet Dienstag der 18. Kalenderwoche 2026.

Nach ISO 8601 beginnt die Woche am Montag. Die erste Kalenderwoche enthält den ersten Donnerstag des Jahres.

Alternativ formuliert: Die erste Kalenderwoche ist die Woche, die mindestens vier Tage im neuen Jahr hat.

Wichtig ist der Unterschied zwischen Kalenderjahr und ISO-Wochenjahr. Rund um den Jahreswechsel können beide voneinander abweichen.

Beispiel:

2021-01-01
2020-W53-5

Der 1. Januar 2021 war ein Freitag und gehörte zur ISO-Kalenderwoche 53 des Wochenjahres 2020.

Dieser Unterschied ist wichtig für Berichte, Fristen, Produktionsplanung und Jahresauswertungen nach Kalenderwochen.

ISO 8601 kennt außerdem Ordinaldaten. Dabei wird der Tag des Jahres angegeben:

2026-118

Diese Angabe bezeichnet den 118. Tag des Jahres 2026. Sie kann in technischen oder wissenschaftlichen Kontexten nützlich sein.

Reduzierte Genauigkeit und erweiterte Jahresangaben

ISO 8601 kann Zeitangaben mit reduzierter Genauigkeit darstellen. Das ist sinnvoll, wenn nur Jahr oder Monat bekannt sind.

Beispiele:

2026
2026-04
2026-04-28

2026 bezeichnet ein Jahr. 2026-04 bezeichnet den Monat April 2026.

Solche Angaben sollten Sie nicht ungeprüft wie vollständige Tageswerte behandeln. Ein Monat ist kein genauer Zeitpunkt.

ISO 8601 kennt außerdem erweiterte Jahresangaben. Sie sind relevant für Jahre außerhalb des Bereichs 0000 bis 9999.

Erweiterte Jahre benötigen in der Regel eine vereinbarte zusätzliche Stellenzahl und ein Vorzeichen.

Beispiele:

+010000-01-01
+012345-04-28
-000001-01-01

Solche Formen müssen zwischen Systemen ausdrücklich vereinbart werden. Nicht jede Datenbank oder API unterstützt erweiterte Jahresdarstellungen.

In ISO-8601-Kontexten mit proleptischem gregorianischem Kalender entspricht Jahr 0000 dem astronomischen Jahr 0, also 1 v. Chr.

Viele fachliche Anwendungen, Archivsysteme und Datenbanken unterstützen oder verwenden diese Darstellung jedoch nicht.

Zeiträume und Dauerangaben

ISO 8601 kann nicht nur konkrete Zeitpunkte, sondern auch Dauern beschreiben. Eine Dauer beginnt mit P für Period.

Beispiel:

P3D

Das bedeutet: eine Dauer von drei Tagen.

Weitere Beispiele:

P1Y
P2M
P4W

P1Y bedeutet ein Jahr. P2M bedeutet zwei Monate. P4W bedeutet vier Wochen.

Jahre und Monate sind kalenderabhängig. P1M bedeutet nicht pauschal 30 Tage, sondern einen Kalendermonat im jeweiligen Kontext.

Für Uhrzeitanteile wird zusätzlich ein T verwendet:

PT2H30M

Das bedeutet: zwei Stunden und 30 Minuten.

Weitere Beispiele:

PT15M
PT8H
P1Y6M
P3DT4H

Wochenangaben wie P4W sollten nicht beliebig mit Jahr-, Monats- und Tageskomponenten kombiniert werden.

Wichtig ist auch der Unterschied zwischen P1D und PT24H.

P1D beschreibt einen Kalendertag. PT24H beschreibt exakt 24 Stunden.

Bei Sommerzeitwechseln kann ein lokaler Kalendertag 23 oder 25 Stunden haben. Dann sind beide Angaben nicht immer gleichwertig.

Dauerangaben sind nützlich für:

• Eskalationsfristen in Workflow-Systemen
• Wiedervorlagen und Erinnerungen
• Gültigkeitszeiträume von Zugriffstoken
• Aufbewahrungsfristen im Archiv
• Service-Level-Agreements
• automatisierte Lösch- und Archivierungsregeln
• Vertragslaufzeiten und Verlängerungsintervalle

Ein Informationsmanagementsystem könnte festlegen, dass ein Dokument nach P10Y zehn Jahre aufbewahrt wird.

Eine Aufgabe könnte nach PT48H eskaliert werden, wenn sie innerhalb von 48 Stunden nicht bearbeitet wurde.

Zeitintervalle nach ISO 8601

Ein Intervall beschreibt einen Zeitraum. Es kann aus Start und Ende, Start und Dauer oder Dauer und Ende bestehen.

Ein Zeitraum mit Start- und Enddatum kann so aussehen:

2026-04-01/2026-04-30

Fachlich bedeutet das häufig: vom 1. April 2026 bis zum 30. April 2026.

Technisch müssen Sie zusätzlich definieren, ob Endpunkte inklusiv oder exklusiv gelten. Auch Uhrzeit und Zeitzone sollten eindeutig sein.

Für technische Abfragen sind halb offene Intervalle oft robuster:

2026-04-01T00:00:00Z/2026-05-01T00:00:00Z

Das kann als >= Start und < Ende interpretiert werden. Dadurch vermeiden Sie Fehler mit 23:59:59.

Ein Zeitraum mit Startzeitpunkt und Dauer kann so aussehen:

2026-04-28T09:00:00Z/PT8H

Das bedeutet: Beginn am 28. April 2026 um 09:00 UTC, Dauer acht Stunden.

Ein Zeitraum mit Dauer und Endwert kann so aussehen:

P7D/2026-04-28

Bei reinem Enddatum bleibt jedoch offen, welcher genaue Endzeitpunkt gemeint ist. Für technische Prozesse sollten Sie präziser formulieren.

Besser ist zum Beispiel:

P7D/2026-04-28T00:00:00Z

Solche Intervalle sind nützlich für Berichte, Zugriffsrechte, Veröffentlichungszeiträume, Kampagnen, Gültigkeiten und Archivregeln.

Wiederholungsintervalle mit R

ISO 8601 kann auch wiederkehrende Zeitangaben darstellen. Wiederholungsintervalle beginnen mit R.

Ein einfaches Beispiel:

R5/P1D

Die Zahl nach R wird häufig als Wiederholungsanzahl beschrieben. In der Praxis kann die Interpretation jedoch variieren.

Manche Systeme verstehen sie als Anzahl zusätzlicher Wiederholungen, andere als Anzahl resultierender Vorkommen oder Intervalle.

Deshalb sollten Sie bei R5 ausdrücklich dokumentieren, wie viele Ereignisse tatsächlich erzeugt werden.

Ein Wiederholungsintervall mit Startzeitpunkt kann so aussehen:

R5/2026-04-28T09:00:00Z/P1D

Diese Angabe beschreibt eine begrenzte tägliche Wiederholung ab dem 28. April 2026 um 09:00 UTC.

Eine offene Wiederholung kann so dargestellt werden:

R/2026-04-28T09:00:00Z/P1D

Das bedeutet eine unbegrenzte Wiederholung ab diesem Startzeitpunkt im Tagesabstand, sofern das System diese Form unterstützt.

Nicht jedes System unterstützt Wiederholungsintervalle. Für APIs und Workflow-Regeln sollten Sie ausdrücklich dokumentieren, ob R erlaubt ist.

ISO 8601-2 und erweiterte Ausdrucksformen

ISO 8601-2 erweitert die Grundformen um zusätzliche Ausdrucksmöglichkeiten. Diese sind vor allem für Archiv-, Bibliotheks- und Records-Management-Kontexte interessant.

Dazu gehören unter anderem unsichere, ungefähre, unvollständige oder offene Datumsangaben.

Je nach Profil können beispielsweise solche Konzepte relevant sein:

2026?
2026~
202X

2026? kann eine unsichere Jahresangabe ausdrücken. 2026~ kann eine ungefähre Jahresangabe markieren.

202X kann für ein nicht vollständig bestimmtes Jahr innerhalb der 2020er-Jahre stehen.

Solche Formen sollten Sie nur verwenden, wenn alle beteiligten Systeme ISO 8601-2 oder ein entsprechendes Profil unterstützen.

Für klassische APIs, Datenbanken und Workflow-Regeln sind die Grundformen aus ISO 8601-1 meist besser geeignet.

ISO 8601 und RFC 3339

In Websystemen, JSON-APIs und OpenAPI-Spezifikationen begegnet Ihnen häufig RFC 3339. Dieser Standard basiert auf ISO 8601.

RFC 3339 ist jedoch ein engeres Profil für Internet-Zeitstempel. Er ist nicht identisch mit dem gesamten ISO-8601-Standard.

Ein typischer RFC-3339-date-time-Wert ist:

2026-04-28T14:30:00Z

Oder mit UTC-Offset:

2026-04-28T16:30:00+02:00

Ein RFC-3339-date-time verlangt einen UTC-Offset oder Z.

Diese Angabe ist deshalb kein vollständiger RFC-3339-date-time-Wert:

2026-04-28T14:30:00

RFC 3339 beschreibt vor allem vollständige Datums- und Zeitangaben mit Offset. Kalenderwochen, Dauern und Wiederholungen gehören nicht zum üblichen RFC-3339-date-time.

Für APIs sollten Sie daher exakt dokumentieren, ob ISO 8601 allgemein oder konkret RFC 3339 erwartet wird.

Legen Sie auch fest, ob Sekundenbruchteile erlaubt sind, ob UTC verpflichtend ist und welche maximale Genauigkeit akzeptiert wird.

FormISO 8601RFC 3339 date-time2026-04-28ja, Kalenderdatumnein, aber RFC 3339 full-date2026-04-28T14:30:00Zjaja2026-04-28T14:30:00+02:00jaja2026-04-28T14:30:00je nach Kontext möglichnein2026-W18-2janein2026-118janeinP3DjaneinR5/P1Dja, wenn unterstütztnein

Kanonische API-Profile

Wenn Sie ISO 8601 in Schnittstellen verwenden, sollten Sie ein kanonisches Profil definieren.

Ein solches Profil legt verbindlich fest, welche Varianten erlaubt sind und welche nicht.

Typische Festlegungen sind:

• vollständiges Datum mit vierstelligem Jahr
• verpflichtendes T zwischen Datum und Uhrzeit
• verpflichtendes Z oder verpflichtender UTC-Offset
• UTC-Pflicht für technische Ereignisse
• erlaubte Sekundenbruchteile
• maximale Anzahl von Nachkommastellen
• Umgang mit Rundung oder Abschneiden
• erlaubte reduzierte Genauigkeiten
• Verbot von Kalenderwochen, Ordinaldaten oder Wiederholungen
• Verhalten bei ungültigen oder mehrdeutigen lokalen Zeiten

Ein mögliches API-Profil kann lauten:

Alle technischen Ereigniszeitpunkte werden als RFC-3339-date-time in UTC übertragen.
Erlaubt sind maximal drei Nachkommastellen für Millisekunden.
Beispiel: 2026-04-28T14:30:00.250Z

So vermeiden Sie, dass verschiedene Clients unterschiedliche ISO-8601-Varianten senden.

ISO 8601 in OpenAPI, JSON Schema und XML

OpenAPI und JSON Schema verwenden häufig format: date und format: date-time.

In der Praxis orientieren sich diese Formate meist an RFC 3339.

Beispiel in OpenAPI:

type: object
properties:
 createdAt:
   type: string
   format: date-time
   example: "2026-04-28T14:30:00Z"
 dueDate:
   type: string
   format: date
   example: "2026-04-30"

format: date steht typischerweise für ein vollständiges Kalenderdatum wie 2026-04-30.

format: date-time steht typischerweise für einen RFC-3339-Zeitstempel mit Offset oder Z.

In Enterprise- und Archivsystemen spielen außerdem XML-Schema-Datentypen eine Rolle.

Wichtige Beispiele sind:

• xs:date für Kalenderdaten
• xs:dateTime für Datums- und Zeitangaben
• xs:time für Uhrzeiten
• xs:duration für Dauern

Diese Datentypen sind ISO-8601-nah, haben aber eigene Regeln. Prüfen Sie deshalb immer das konkrete Schema und die Implementierung.

Vorteile von ISO 8601 in Informationsmanagementsystemen

In Informationsmanagementsystemen werden Zeitangaben häufig systemübergreifend verarbeitet.

Das betrifft Dokumente, Versionen, Freigaben, Archivierungsfristen, Protokolldaten und Compliance-Nachweise.

Wichtige Vorteile sind:

• Eindeutigkeit: Datumsangaben werden international klarer verstanden.
• Sortierbarkeit: Vollständige Kalenderdaten im gleichen Format lassen sich chronologisch korrekt sortieren.
• Systemkompatibilität: Viele Datenbanken, APIs, Programmiersprachen und Anwendungen unterstützen ISO-8601-nahe Formate.
• Fehlervermeidung: Missverständnisse durch regionale Schreibweisen werden reduziert.
• Nachvollziehbarkeit: Zeitangaben in Logs, Workflows und Dokumenthistorien sind leichter auswertbar.
• Automatisierung: Fristberechnung, Wiedervorlage, Eskalation und Archivierung lassen sich zuverlässiger steuern.
• Compliance-Unterstützung: Audit-Trails und Nachweispflichten profitieren von eindeutigen Zeitangaben.
• Datenqualität: Einheitliche Formate erleichtern Validierung, Migration und Integration.
• Internationale Skalierbarkeit: Systeme können standort- und länderübergreifend konsistenter arbeiten.

Ein praktisches Beispiel:

2026-04-28T16:30:00+02:00
2026-04-28T14:30:00Z

Beide Angaben beschreiben denselben Zeitpunkt. ISO 8601 macht diesen Zusammenhang maschinenlesbar.

Beispiele aus der Praxis

ISO 8601 wird in vielen digitalen Prozessen verwendet. Die folgenden Beispiele zeigen typische Anwendungen in Informationsmanagement und Integration.

Dokumentenmanagement

Ein Dokument kann mit einem Erstellungsdatum gespeichert werden:

2026-04-28

Oder mit einem genauen Zeitpunkt:

2026-04-28T09:15:30+02:00

So ist nachvollziehbar, wann ein Dokument erstellt, geändert, geprüft oder freigegeben wurde.

Eine Dokumenthistorie könnte so aussehen:

2026-04-28T09:15:30+02:00 Dokument erstellt
2026-04-28T10:05:12+02:00 Dokument zur Prüfung eingereicht
2026-04-29T08:45:00+02:00 Dokument freigegeben

Das ist relevant für Verträge, Qualitätsdokumente, technische Zeichnungen, Richtlinien, Rechnungen und revisionspflichtige Unterlagen.

Schnittstellen und APIs

APIs verwenden häufig ISO-8601- oder RFC-3339-Zeitangaben, um Daten zwischen Systemen auszutauschen:

{
 "createdAt": "2026-04-28T14:30:00Z",
 "updatedAt": "2026-04-28T15:10:45Z",
 "archivedAt": null
}

Dadurch können Systeme in unterschiedlichen Ländern dieselbe Zeitinformation korrekt interpretieren.

Das ist wichtig bei Integrationen zwischen Dokumentenmanagement, ERP, CRM, E-Mail-Archivierung, Data Warehouses und BI-Lösungen.

Dateibenennung

Für regelmäßig erzeugte Dateien ist ein ISO-8601-nahes Format praktisch:

2026-04-28_export.csv
2026-04-29_export.csv
2026-04-30_export.csv

Die Dateien erscheinen bei gleicher Struktur automatisch in der richtigen Reihenfolge.

Wenn Uhrzeiten in Dateinamen verwendet werden, sind Doppelpunkte in manchen Dateisystemen problematisch.

Der Zeitstempelteil dieser Zeichenfolge ist ISO-8601-konform im Basisformat:

20260428T093000Z

Als Bestandteil eines Dateinamens kann er so verwendet werden:

20260428T093000Z_export.csv

Der gesamte Dateiname ist jedoch keine ISO-8601-Datums- oder Zeitangabe.

Eine dateisystemfreundliche technische Konvention kann auch so aussehen:

2026-04-28T09-30-00Z_export.csv

Diese zweite Variante ist praktisch, aber nicht streng ISO-8601-konform. Sie sollte daher als interne Dateinamenskonvention dokumentiert werden.

Audit-Logs

In Protokolldateien helfen Zeitangaben, Ereignisse exakt nachzuvollziehen:

2026-04-28T08:12:05Z User login successful
2026-04-28T08:14:22Z Document approved
2026-04-28T08:17:09Z Permission changed

Das ist wichtig für Compliance, IT-Sicherheit, interne Revisionen und forensische Analysen.

Bei Sicherheitsvorfällen müssen Ereignisse aus verschiedenen Systemen zeitlich korrekt zusammengeführt werden.

ISO-8601-Zeitangaben mit gemeinsamer Zeitbasis erleichtern diese Korrelation.

Workflows und Fristen

In Workflow-Systemen können ISO-8601-Angaben genutzt werden, um Fristen eindeutig zu berechnen:

{
 "taskId": "APP-1042",
 "createdAt": "2026-04-28T09:00:00Z",
 "dueAt": "2026-04-30T09:00:00Z",
 "escalationAfter": "PT48H"
}

Damit ist klar, wann eine Aufgabe erstellt wurde, wann sie fällig ist und nach welcher Dauer eine Eskalation erfolgt.

Gerade bei Genehmigungen, Rechnungsprüfungen, Reklamationen oder Serviceanfragen reduziert das Fehlinterpretationen.

Archivierung und Records Management

Auch bei Aufbewahrungsfristen ist ISO 8601 hilfreich. Ein System kann Archivierungszeitpunkt, Dauer und Löschdatum strukturiert speichern.

{
 "recordId": "REC-2026-00017",
 "archivedAt": "2026-04-28T12:00:00Z",
 "retentionPeriod": "P10Y",
 "deleteAfter": "2036-04-28"
}

So lassen sich Aufbewahrungs- und Löschregeln nachvollziehbar automatisieren.

Voraussetzung ist, dass Datum, Dauer, Zeitzone oder UTC-Offset einheitlich interpretiert werden.

Best Practices für die Nutzung von ISO 8601

Wenn Sie ISO 8601 einsetzen, sollten Sie klare Regeln für Speicherung, Anzeige, Schnittstellen und Dokumentation definieren.

Empfehlenswerte Best Practices sind:

• Verwenden Sie vollständige Kalenderdaten wie 2026-04-28, wenn ein konkreter Tag gemeint ist.
• Speichern Sie technische Ereigniszeitpunkte möglichst eindeutig, häufig in UTC.
• Geben Sie bei global relevanten Zeitangaben einen UTC-Offset oder Z an.
• Nutzen Sie benannte Zeitzonen zusätzlich, wenn zukünftige lokale Termine relevant sind.
• Zeigen Sie Nutzern lokale Zeiten entsprechend Sprache, Region und Zeitzone an.
• Trennen Sie Anzeigeformat und Speicherformat konsequent.
• Definieren Sie, ob Sie ISO 8601 allgemein oder RFC 3339 als API-Profil verwenden.
• Dokumentieren Sie, ob Sekundenbruchteile erlaubt oder verpflichtend sind.
• Legen Sie fest, welche Genauigkeit für welchen Anwendungsfall benötigt wird.
• Verwenden Sie führende Nullen, etwa 2026-04-08 statt 2026-4-8.
• Validieren Sie Eingaben syntaktisch und kalendarisch.
• Vermeiden Sie unklare Freitextangaben wie morgen 9 Uhr in technischen Prozessen.
• Verwenden Sie für Tagesbereiche bevorzugt halb offene Intervalle.
• Normalisieren Sie Zeitpunkte für Sortierung und Vergleich möglichst auf dieselbe Zeitbasis.
• Dokumentieren Sie Schnittstellenformate mit Beispielen und Grenzfällen.

Eine sinnvolle Architektur speichert technische Zeitpunkte häufig in UTC und gibt sie über Schnittstellen eindeutig formatiert aus.

Benutzeroberflächen können dieselben Werte lokalisiert anzeigen, ohne das interne Speicherformat zu verändern.

Präzision, Rundung und Sekundenbruchteile

Digitale Systeme speichern Zeitangaben mit unterschiedlicher Präzision.

Häufige Genauigkeiten sind Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden.

Beispiele:

2026-04-28T14:30:00Z
2026-04-28T14:30:00.250Z
2026-04-28T14:30:00.250123Z
2026-04-28T14:30:00.250123456Z

Probleme entstehen, wenn ein System höhere Präzision liefert als ein anderes System speichern kann.

Beim Abschneiden oder Runden können Reihenfolgen, Fristen und Audit-Ereignisse verändert wirken.

Dokumentieren Sie deshalb, wie viele Nachkommastellen erlaubt sind und ob Werte gerundet oder abgeschnitten werden.

Für beweisrelevante Ereignisse sollten Zeitangaben unverändert, nachvollziehbar und mit klarer Zeitbasis gespeichert werden.

Typische Fehler und Missverständnisse

Obwohl ISO 8601 klare Regeln vorgibt, entstehen in der Praxis immer wieder ähnliche Fehler.

Sie treten besonders häufig bei Schnittstellen, Datenmigrationen, Berichtssystemen und international genutzten Anwendungen auf.

Fehlender UTC-Offset

2026-04-28T14:30:00

Diese Angabe enthält keinen UTC-Offset. Es ist daher nicht eindeutig, ob 14:30 Uhr in Berlin, UTC oder anderswo gemeint ist.

Besser für globale Ereignisse:

2026-04-28T14:30:00Z

Oder:

2026-04-28T16:30:00+02:00

Wenn eine Anwendung lokale Zeitangaben ohne Offset verarbeitet, muss die angenommene Zeitzone klar dokumentiert sein.

UTC-Offset mit Zeitzone verwechseln

+02:00 ist ein UTC-Offset, aber keine vollständige Zeitzone. Er enthält keine Sommerzeitregeln.

Die Zeitzone Europe/Berlin kann je nach Datum +01:00 oder +02:00 verwenden.

Für vergangene technische Ereignisse reicht oft der konkrete UTC-Zeitpunkt. Für zukünftige lokale Termine ist die benannte Zeitzone oft erforderlich.

Formatmuster mit Library-Strings gleichsetzen

Platzhalter wie YYYY-MM-DD erklären ISO-8601-Strukturen. Sie sind nicht automatisch gültige Formatstrings jeder Programmiersprache.

In manchen Bibliotheken steht YYYY für das Wochenjahr, nicht für das Kalenderjahr.

Ebenso kann DD den Tag des Jahres bedeuten, während dd den Tag des Monats beschreibt.

Auch MM und mm unterscheiden sich häufig: MM steht oft für Monat, mm für Minute.

Prüfen Sie deshalb immer die Dokumentation Ihrer konkreten Technologie.

Regionale Schreibweisen in internationalen Systemen

Formate wie 28.04.2026 oder 04/28/2026 sind für Menschen lesbar, aber nicht international eindeutig.

Für Speicherung, Exporte und Schnittstellen sollten Sie eindeutige ISO-8601- oder RFC-3339-Formate bevorzugen.

Regionale Anzeigeformate sind dennoch sinnvoll, wenn sie nur in der Benutzeroberfläche verwendet werden.

Sommerzeit und lokale Uhrzeiten

Zeitumstellungen können dazu führen, dass lokale Uhrzeiten doppelt vorkommen oder gar nicht existieren.

Bei der Umstellung auf Winterzeit kann 02:30 in bestimmten Regionen zweimal auftreten.

Bei der Umstellung auf Sommerzeit kann eine lokale Uhrzeit übersprungen werden.

Ohne Offset oder benannte Zeitzone ist dann nicht eindeutig, welcher Zeitpunkt gemeint ist.

Uneinheitliche Genauigkeit

Manche Systeme speichern nur ein Datum, andere Stunden, Minuten, Sekunden oder Millisekunden.

Beispiel:

2026-04-28
2026-04-28T00:00:00Z
2026-04-28T00:00:00.000Z

Diese Werte wirken ähnlich, bedeuten aber je nach Kontext nicht zwingend dasselbe.

Ein fachliches Datum wie ein Geburtstag ist kein Zeitpunkt um Mitternacht UTC.

Ungültige Kalenderwerte

Ein Wert kann formal ähnlich aussehen und trotzdem kalendarisch ungültig sein.

Beispiele:

2026-02-30
2026-13-01
2026-00-10
2026-04-31
25:00:00

Diese Strukturen ähneln ISO-8601-Angaben, sind aber keine gültigen Kalender- oder Uhrzeitwerte.

Validierung sollte daher nicht nur das Muster, sondern auch Kalenderregeln prüfen.

End-of-day-Werte

Viele Systeme modellieren Tagesenden mit 23:59:59. Das kann bei Millisekunden, Mikrosekunden oder Zeitzonen fehleranfällig sein.

Robuster sind halb offene Intervalle:

>= 2026-04-28T00:00:00Z
< 2026-04-29T00:00:00Z

So vermeiden Sie Lücken am Tagesende.

Tests und Validierung

ISO-8601-nahe Zeichenketten sollten nicht nur optisch geprüft werden.

Eine gute Validierung umfasst mehrere Ebenen:

• syntaktische Prüfung des erlaubten Formats
• kalendarische Prüfung gültiger Tage und Monate
• Schaltjahrprüfung
• Prüfung erlaubter Uhrzeiten
• Prüfung erlaubter UTC-Offsets
• Prüfung der Zeitzonenregeln bei lokalen Terminen
• Prüfung erlaubter Sekundenbruchteile
• Roundtrip-Tests zwischen beteiligten Systemen
• Tests für Jahreswechsel und Kalenderwochen
• Tests für Sommerzeitwechsel
• Tests für minimale und maximale unterstützte Werte

Roundtrip-Tests sind besonders wichtig. Ein Wert wird exportiert, importiert und erneut exportiert.

Danach sollte klar sein, ob Wert, Genauigkeit, Offset und fachliche Bedeutung erhalten geblieben sind.

ISO 8601 und Datenqualität

Einheitliche Zeitformate sind ein wichtiger Bestandteil guter Datenqualität.

In Informationsmanagementsystemen hängen viele Prozesse davon ab, dass Datums- und Zeitwerte korrekt, vollständig und vergleichbar sind.

ISO 8601 unterstützt die Datenqualität in mehreren Bereichen:

• Konsistenz: Systeme verwenden dieselbe Struktur für Zeitangaben.
• Validierbarkeit: Werte lassen sich automatisiert auf gültige Formate prüfen.
• Vergleichbarkeit: Zeitpunkte können zuverlässig sortiert, gefiltert und ausgewertet werden.
• Nachvollziehbarkeit: Änderungen, Freigaben und Zugriffe können zeitlich rekonstruiert werden.
• Integrationsfähigkeit: Daten können leichter zwischen Anwendungen, Plattformen und Datenbanken übertragen werden.

Gerade bei Datenmigrationen ist ISO 8601 hilfreich.

Wenn Altsysteme regionale oder uneinheitliche Formate verwenden, sollten Datumswerte vor der Übernahme bereinigt werden.

Dadurch vermeiden Sie spätere Fehler in Workflows, Reports und Archivierungsregeln.

Datenschutz, Compliance und Nachweisbarkeit

Zeitangaben können personenbezogene oder beweisrelevante Informationen sein. Ein Zeitstempel kann zeigen, wann eine Person angemeldet war, ein Dokument geöffnet oder eine Freigabe erteilt hat. Deshalb sollten solche Werte konsistent, unverändert und nachvollziehbar gespeichert werden.

Für Compliance-Zwecke ist wichtig, dass Zeitbasis, Genauigkeit, Quelle und mögliche Veränderungen dokumentiert sind.

Audit-Trails sollten erkennen lassen, ob ein Wert original übernommen, normalisiert, gerundet oder nachträglich korrigiert wurde.

Bei personenbezogenen Zeitangaben gelten außerdem Datenschutzanforderungen, etwa Zweckbindung, Zugriffsschutz und Aufbewahrungsfristen.

ISO 8601 in APIs, Datenbanken und Cloud-Systemen

Moderne Informationslandschaften bestehen häufig aus mehreren Anwendungen, die über Schnittstellen verbunden sind.

ISO 8601 ist hier ein bewährtes Austauschformat, weil es von vielen Technologien verstanden wird.

In APIs werden Zeitangaben häufig als Zeichenketten übertragen:

{
 "documentId": "DOC-10045",
 "createdAt": "2026-04-28T11:20:00Z",
 "lastModifiedAt": "2026-04-28T13:45:30Z"
}

Für Datenbanken sind meist native Datums- und Zeitdatentypen vorzuziehen.

ISO 8601 eignet sich besonders für Import, Export, APIs, Logs und Dokumentation.

Typische Datenbanktypen sind:

• DATE für reine Kalenderdaten
• TIME für Uhrzeiten ohne Datum
• TIMESTAMP WITHOUT TIME ZONE für lokale oder kontextabhängige Zeitangaben
• TIMESTAMP WITH TIME ZONE für zeitpunktbezogene Werte, je nach Datenbanksystem

Die genaue Bedeutung variiert je nach Datenbanksystem.

In PostgreSQL speichert TIMESTAMP WITH TIME ZONE beispielsweise keine ursprüngliche Zeitzone wie Europe/Berlin.

Stattdessen wird ein Zeitpunkt normalisiert gespeichert. Die Anzeige erfolgt abhängig von der Session-Zeitzone.

Dokumentieren Sie deshalb, welche fachliche Bedeutung ein Feld hat.

Wichtig ist die Unterscheidung: Handelt es sich um ein reines Datum, einen lokalen Termin oder einen globalen Zeitpunkt?

Für Cloud-Systeme ist diese Unterscheidung besonders relevant. Server, Nutzer und angebundene Anwendungen können in unterschiedlichen Zeitzonen arbeiten.

Unterschied zwischen ISO 8601, Unix Timestamp und lokalem Datumsformat

ISO 8601 ist nicht die einzige Möglichkeit, Zeitpunkte darzustellen.

In technischen Systemen begegnen Ihnen auch Unix Timestamps, native Datenbanktypen und lokale Datumsformate.

FormatBeispielVorteilTypischer EinsatzISO 86012026-04-28T14:30:00Zlesbar und maschinenlesbarAPIs, Logs, ExporteUnix Timestamp1777386600kompakt und gut berechenbarinterne VerarbeitungDatenbanktypTIMESTAMP WITH TIME ZONEtypisiert und abfragbarrelationale DatenbankenLokales Datumsformat28.04.2026 16:30nutzerfreundlichOberflächen und Berichte

ISO 8601 eignet sich besonders gut als Austauschformat. Unix Timestamps sind effizient, aber für Menschen schwer interpretierbar.

Lokale Datumsformate sind angenehm für Nutzer, aber für internationale Verarbeitung weniger geeignet.

In vielen Systemen ist eine Kombination sinnvoll: native Speicherung, Austausch über ISO 8601 oder RFC 3339 und Anzeige im lokalen Nutzerformat.

Häufige Fragen zu ISO 8601

Was ist ISO 8601 einfach erklärt?

ISO 8601 ist ein internationaler Standard für die Darstellung von Datums- und Zeitangaben. Er sorgt dafür, dass Zeitangaben eindeutig, international verständlich und maschinenlesbar dargestellt werden können.

Ein typisches Kalenderdatum ist:

2026-04-28

Ist ISO ein Akronym?

Nein. ISO ist der offizielle Kurzname der International Organization for Standardization. Der Name wird international einheitlich verwendet und ist kein Akronym der englischen Organisationsbezeichnung.

Wie sieht ein Datum nach ISO 8601 aus?

Ein häufiges ISO-8601-Datum im erweiterten Kalenderformat sieht so aus:

2026-04-28

Das Basisformat ohne Trennzeichen ist ebenfalls möglich:

20260428

Beide Angaben beschreiben den 28. April 2026.

Ist die ISO-8601-Reihenfolge immer Jahr-Monat-Tag?

Nein. Jahr-Monat-Tag gilt für Kalenderdaten wie 2026-04-28. ISO 8601 kennt aber auch Kalenderwochendaten wie 2026-W18-2 und Ordinaldaten wie 2026-118. Außerdem sind reduzierte Genauigkeiten wie 2026 oder 2026-04 möglich.

Wie werden Datum und Uhrzeit nach ISO 8601 geschrieben?

Datum und Uhrzeit werden mit einem T getrennt:

2026-04-28T14:30:00

Mit UTC-Angabe sieht die Zeitangabe so aus:

2026-04-28T14:30:00Z

Diese Schreibweise wird häufig in APIs, Datenbanken, Logdateien und Informationsmanagementsystemen verwendet.

Was bedeutet das Z am Ende einer Zeitangabe?

Das Z steht für UTC, die koordinierte Weltzeit.

Beispiel:

2026-04-28T14:30:00Z

Diese Angabe bedeutet, dass die Uhrzeit in UTC angegeben ist.

Ist ISO 8601 dasselbe wie UTC?

Nein. ISO 8601 ist ein Standard für die Darstellung von Datums- und Zeitangaben. UTC ist eine Zeitbasis. ISO 8601 kann UTC darstellen, zum Beispiel mit Z. ISO 8601 kann auch UTC-Offsets wie +02:00 oder -05:00 darstellen.

Was ist der Unterschied zwischen UTC-Offset und Zeitzone?

Ein UTC-Offset wie +02:00 beschreibt nur die Abweichung von UTC zu einem bestimmten Zeitpunkt. Eine Zeitzone wie Europe/Berlin enthält zusätzlich Regeln für Sommerzeit und historische Änderungen. ISO 8601 stellt Offsets dar, ersetzt aber keine benannten IANA-Zeitzonen.

Ist 2026-04-28T14:30:00 eindeutig?

Nicht vollständig. Diese Angabe enthält keine Zeitzone und keinen UTC-Offset. Sie kann als lokale oder kontextabhängige Zeit verstanden werden. Für globale Ereignisse sollten Sie Z oder einen UTC-Offset ergänzen.

Ist 2026-04-28T14:30:00 ein RFC-3339-date-time?

Nein. RFC 3339 verlangt bei date-time einen UTC-Offset oder Z.

Gültige Beispiele sind:

2026-04-28T14:30:00Z
2026-04-28T16:30:00+02:00

Sollte man ISO 8601 in Datenbanken verwenden?

Für Datenbanken sollten Sie meist native Datums- und Zeitdatentypen verwenden. ISO 8601 eignet sich besonders für Austausch, Import, Export, Logs, APIs und Dokumentation. Wichtig ist, die fachliche Bedeutung eines Feldes klar zu definieren: Datum, lokale Zeit oder globaler Zeitpunkt.

Beginnt die Woche nach ISO 8601 am Montag oder Sonntag?

Nach ISO 8601 beginnt die Woche am Montag. Die erste Kalenderwoche eines Jahres ist die Woche, die den ersten Donnerstag enthält. Dadurch können Kalenderwochen international einheitlich berechnet werden.

Was bedeutet 2026-W18?

2026-W18 bezeichnet die 18. Kalenderwoche des Jahres 2026.

Ein bestimmter Tag innerhalb dieser Woche kann zusätzlich angegeben werden:

2026-W18-2

Das bedeutet Dienstag der 18. Kalenderwoche 2026.

Kann der 1. Januar zum ISO-Wochenjahr des Vorjahres gehören?

Ja. ISO-Wochenjahr und Kalenderjahr können rund um den Jahreswechsel voneinander abweichen. Der 1. Januar 2021 gehörte beispielsweise zu 2020-W53-5. Das ist besonders wichtig für Berichte und Auswertungen nach Kalenderwochen.

Was bedeutet 2026-118?

2026-118 ist ein Ordinaldatum. Es bezeichnet den 118. Tag des Jahres 2026. Diese Darstellung wird seltener genutzt, kann aber in technischen und wissenschaftlichen Kontexten praktisch sein.

Was bedeutet P3D in ISO 8601?

P3D ist eine Dauerangabe und bedeutet drei Tage. Das P steht für Period.

Bedeutet P1M immer 30 Tage?

Nein. P1M bedeutet ein Kalendermonat, nicht pauschal 30 Tage. Die tatsächliche Länge hängt vom konkreten Startdatum und vom Kalenderkontext ab. Für exakt 30 Tage sollten Sie P30D verwenden.

Ist P1D dasselbe wie PT24H?

Nicht immer. P1D beschreibt einen Kalendertag, PT24H beschreibt exakt 24 Stunden. Bei Sommerzeitwechseln kann ein lokaler Kalendertag 23 oder 25 Stunden haben. Für technische Fristen sollten Sie deshalb genau festlegen, welche Bedeutung gemeint ist.

Was bedeutet PT2H30M?

PT2H30M bedeutet zwei Stunden und 30 Minuten. Das T trennt bei Dauerangaben den Datumsanteil vom Zeitanteil. H steht für Stunden, M steht in diesem Kontext für Minuten.

Was bedeutet R5/P1D?

R5/P1D beschreibt ein Wiederholungsintervall. Die genaue Anzahl resultierender Ereignisse kann je nach Implementierung unterschiedlich interpretiert werden. R5 fünf Wiederholungen, fünf Intervalle oder fünf Vorkommen bedeutet.

Welches ISO-8601-Format eignet sich für APIs?

Für APIs eignet sich häufig ein vollständiger Zeitwert mit UTC oder UTC-Offset.

Beispiel:

2026-04-28T14:30:00Z

In Web-APIs wird oft konkret RFC 3339 verlangt. Dokumentieren Sie daher Format, Offset-Pflicht und Sekundenbruchteile genau.

Kann ISO 8601 auch ohne Uhrzeit verwendet werden?

Ja. Wenn nur ein Datum benötigt wird, reicht zum Beispiel:

2026-04-28

Das eignet sich für Geburtstage, Stichtage, Vertragsdaten oder reine Kalendereinträge.

Was sind erweiterte Jahresangaben in ISO 8601?

Erweiterte Jahresangaben ermöglichen Jahre außerhalb des Bereichs 0000 bis 9999. Sie benötigen meist eine vereinbarte Stellenzahl und ein Vorzeichen.

Beispiel:

+010000-01-01

Solche Angaben sollten Sie nur verwenden, wenn alle beteiligten Systeme sie unterstützen.

Was bedeutet Jahr 0000 in ISO-8601-Kontexten?

Bei proleptischem gregorianischem Kalender entspricht Jahr 0000 dem astronomischen Jahr 0, also 1 v. Chr. Viele fachliche Anwendungen und Datenbanken unterstützen diese Darstellung jedoch nicht. Sie sollten deshalb prüfen, ob Jahr 0000 in Ihrem System erlaubt ist.

Warum ist ISO 8601 für Informationsmanagementsysteme besonders relevant?

Informationsmanagementsysteme verarbeiten Dokumente, Versionen, Freigaben, Fristen, Audit-Logs und Archivierungsregeln. ISO 8601 sorgt dafür, dass diese Zeitangaben eindeutiger, sortierbarer und systemübergreifend interpretierbar bleiben. Dadurch verbessern Sie Datenqualität, Prozesssicherheit und Nachvollziehbarkeit.

‍