Format de date et heure ISO 8601 expliqué
ISO 8601 est le standard international pour représenter les dates et heures sous forme de chaînes. Sa forme canonique — 2024-03-15T14:30:00Z — est sans ambiguïté, triable et prise en charge dans tous les langages et bases de données modernes. Ce guide couvre le format composant par composant, le sous-ensemble RFC 3339 que la plupart des API utilisent réellement, la nouvelle extension de fuseau RFC 9557, et les variantes pour les durées, intervalles et dates de semaine.
Qu'est-ce que ISO 8601 ?
ISO 8601 est la représentation des dates et heures de l'Organisation internationale de normalisation. La version actuelle (ISO 8601-1:2019 / -2:2019) définit un format texte compact, ordonné et neutre vis-à-vis de la langue. Tout son but est d'éliminer l'ambiguïté : une date comme 03/04/2024 est le 4 mars aux États-Unis et le 3 avril dans la majeure partie de l'Europe, mais 2024-03-04 signifie la même chose partout. Le standard est aussi la base de RFC 3339, le profil réellement utilisé par la plupart des protocoles internet.
- Ordre année-mois-jour, toujours : 2024-03-15 (pas 03/15/2024 ni 15/03/2024)
- Partie heure séparée par un T littéral ou un espace : 2024-03-15T14:30:00
- Fuseau explicite : Z pour UTC, ou ±HH:MM pour un décalage
- Triable en tant que texte — l'ordre lexicographique correspond à l'ordre chronologique
Le format canonique de date-heure
La forme la plus courante ressemble à 2024-03-15T14:30:00.123Z. Chaque composant est de largeur fixe et complété par des zéros, et c'est ce qui rend le format triable et sans ambiguïté.
| Composant | Exemple | Signification |
|---|---|---|
| YYYY | 2024 | Année à quatre chiffres |
| MM | 03 | Mois à deux chiffres (01–12) |
| DD | 15 | Jour à deux chiffres (01–31) |
| T | T | Séparateur date/heure (RFC 3339 autorise aussi un espace) |
| hh:mm:ss | 14:30:00 | Heure sur 24 h, complétée par des zéros |
| .fff | .123 | Secondes fractionnaires optionnelles (précision arbitraire en ISO 8601) |
| Z ou ±hh:mm | Z | Désignateur de fuseau (Z = UTC = +00:00) |
Désignateurs de fuseau
Les fuseaux ISO 8601 sont encodés comme des décalages par rapport à UTC, jamais comme des abréviations de zone telles que EST ou CET (qui sont ambiguës). La chaîne porte assez d'information pour reconstruire l'instant UTC exact, y compris les décalages d'une demi-heure et de 45 minutes utilisés par certaines régions.
| Désignateur | Décalage par rapport à UTC | Zone d'exemple |
|---|---|---|
| Z | +00:00 | UTC (heure "Zulu") |
| +09:00 | 9 heures en avance | Heure normale du Japon |
| -05:00 | 5 heures en retard | Heure normale de l'Est (États-Unis) |
| +05:30 | 5,5 heures en avance | Heure normale de l'Inde |
| +05:45 | 5,75 heures en avance | Heure normale du Népal |
| (aucun) | non spécifié | Heure locale — ambiguë ; à éviter dans les API |
ISO 8601 vs RFC 3339
RFC 3339 est un profil d'ISO 8601 — plus restrictif et plus facile à parser. La plupart des protocoles internet (API JSON, HTTP, spécifications IETF) visent spécifiquement RFC 3339, donc quand une API dit "ISO 8601", elle désigne presque toujours le sous-ensemble RFC 3339. Les différences sont petites mais elles décident si une chaîne donnée se parse.
| Caractéristique | ISO 8601 | RFC 3339 |
|---|---|---|
| Séparateur date/heure | T, ou omis dans le format de base | T ou un seul espace (obligatoire) |
| Décalage de fuseau | Optionnel | Obligatoire |
| Secondes fractionnaires | Précision arbitraire | Autorisées, limitées par le parseur |
| Format de base (sans tirets) | 20240315T143000Z autorisé | Non autorisé |
| Dates de semaine/ordinales | Autorisées | Non autorisées |
| Usage typique | Archives, tableurs, échange | API JSON, HTTP, spécifications IETF |
RFC 9557 : les fuseaux et l'extension Temporal
Un simple décalage comme +01:00 vous dit l'instant mais pas le fuseau — et les décalages changent avec l'heure d'été, donc le même fuseau est +01:00 en hiver et +02:00 en été. RFC 9557 (2024) comble cette lacune avec l'Internet Extended Date/Time Format (IXDTF) : il ajoute le nom de zone IANA entre crochets, comme dans 2024-03-15T14:30:00+01:00[Europe/Paris]. C'est le format de chaîne que l'API Temporal de JavaScript lit et écrit, vous le verrez donc davantage à mesure que Temporal se répand. Il reste rétrocompatible — retirez le suffixe entre crochets et vous avez un timestamp RFC 3339 ordinaire.
- Décalage seul : 2024-03-15T14:30:00+01:00 — l'instant, mais pas le fuseau
- IXDTF (RFC 9557) : 2024-03-15T14:30:00+01:00[Europe/Paris] — instant plus fuseau
- Rétrocompatible : l'étiquette entre crochets est ignorable par les parseurs RFC 3339
Variantes : durées, intervalles, dates de semaine
ISO 8601 couvre plus que les instants. Plusieurs variantes reviennent régulièrement dans les systèmes de planification, d'archivage et de reporting :
- Durées : P3Y6M4DT12H30M5S = 3 ans, 6 mois, 4 jours, 12 heures, 30 minutes, 5 secondes
- Intervalles : 2024-01-01/2024-02-01, ou 2024-01-01/P1M (début + durée)
- Dates ordinales : 2024-075 = le 75e jour de 2024 (15 mars)
- Dates de semaine : 2024-W11-5 = vendredi de la semaine ISO 11 de 2024
- Intervalles répétés : R3/2024-01-01/P1D = trois intervalles d'un jour à partir du 1er janvier
ISO 8601 dans le code
Tout langage courant peut produire et parser le sous-ensemble RFC 3339 nativement. L'habitude la plus sûre est d'émettre en UTC avec un Z et de reparser vers un instant, en laissant toute conversion de fuseau à la couche d'affichage.
- JavaScript émettre : new Date().toISOString() // '2024-03-15T14:30:00.123Z'
- JavaScript parser : new Date('2024-03-15T14:30:00Z') // sous-ensemble RFC 3339
- Python émettre : datetime.now(timezone.utc).isoformat()
- Python parser : datetime.fromisoformat('2024-03-15T14:30:00+00:00') // ISO complet en 3.11+
- La plupart des bases de données (Postgres, SQLite) acceptent et renvoient ISO 8601 timestamptz directement
Erreurs courantes en ISO 8601
Même avec un standard strict, le code de parsing et d'émission fait la même poignée d'erreurs :
- Omettre le fuseau : 2024-03-15T14:30:00 sans Z ni décalage est ambigu
- Utiliser "+0000" au lieu de "+00:00" — certains parseurs l'acceptent, pas RFC 3339
- Utiliser un T non-lettre (les sosies Unicode se copient mal)
- Mélanger l'AM/PM sur 12 h dans ISO 8601 — c'est toujours sur 24 h
- Tronquer les secondes fractionnaires sans arrondir — choisissez une précision et tenez-vous-y
- Traiter ISO 8601 comme dépendant de la locale — il ne l'est pas ; le format est fixe quelle que soit la langue
Références associées
FAQ
- "2024-03-15 14:30:00Z" est-il du ISO 8601 valide ?
- Oui — l'espace entre la date et l'heure est autorisé en ISO 8601 (et en RFC 3339). La forme avec T est préférable pour un parsing machine sans ambiguïté.
- Que signifie le Z à la fin ?
- Z signifie UTC (décalage +00:00). C'est l'abréviation de "heure Zulu", l'alphabet phonétique OTAN/aviation pour la lettre Z.
- Comment parser de l'ISO 8601 en JavaScript ?
- new Date("2024-03-15T14:30:00Z") fonctionne pour le sous-ensemble RFC 3339 standard. Pour une prise en charge ISO 8601 plus large, utilisez une bibliothèque comme date-fns ou l'API Temporal.
- ISO 8601 est-il la même chose que RFC 3339 ?
- Non — RFC 3339 est un sous-ensemble strict. Tout timestamp RFC 3339 est du ISO 8601 valide, mais tout timestamp ISO 8601 n'est pas du RFC 3339 valide.
- Qu'est-ce que RFC 9557 ?
- RFC 9557 (2024) étend RFC 3339 avec l'Internet Extended Date/Time Format (IXDTF). Il ajoute le nom de fuseau IANA entre crochets — par exemple 2024-03-15T14:30:00+01:00[Europe/Paris] — et sous-tend le format de chaîne utilisé par l'API Temporal de JavaScript.
- Le séparateur T est-il obligatoire ?
- En ISO 8601 strict, le T peut être omis dans le format de base ; RFC 3339 exige un T ou un seul espace. Pour le parsing machine, incluez toujours le T.
- Quelle est la différence entre ISO 8601 et ISO 8601-2 ?
- ISO 8601-1 couvre la représentation de base des dates et heures. ISO 8601-2 (l'extension de 2019) ajoute de nouvelles constructions comme les dates incertaines, les valeurs qualifiantes et les intervalles complexes.