Format ISO 8601 : analyseur et validateur

Qu'est-ce que le format ISO 8601 ?

ISO 8601 est la norme internationale pour écrire les dates et les heures de façon qu'elles se trient correctement, se lisent pareil dans tous les pays et ne laissent personne se demander si 03/08 désigne mars ou août. Son écriture la plus connue est celle que presque tout le monde a en tête en disant « le format ISO 8601 » : la date sous la forme 2026-08-03, l'heure derrière un T et le décalage par rapport à UTC à la fin, ce qui donne 2026-08-03T12:00:00Z.

La norme est nettement plus large que cette seule écriture, et c'est de là que naît l'essentiel de la confusion. ISO 8601 définit aussi des dates sans séparateurs, des dates qui donnent le quantième de l'année au lieu du mois, des dates qui numérotent la semaine au lieu du jour, des durées et des intervalles entre deux points. Tout cela est de l'ISO 8601. Bien peu de logiciels acceptent tout cela.

Un validateur qui répond seulement « valide » ou « invalide » répond donc à une question qui n'a pas de réponse unique. Celui-ci donne trois verdicts côte à côte — ISO 8601, RFC 3339 et le format que définit JavaScript — parce qu'une chaîne peut être irréprochable pour l'un et se faire refuser par les deux autres, et que savoir lequel est lequel est ce qui aide vraiment.

Comment utiliser l'analyseur

1. Collez votre chaîne. Une date, une date avec heure, une durée commençant par P ou un intervalle avec une barre oblique au milieu. Les boutons d'exemple en chargent un de chaque, dont deux que la plupart des analyseurs refusent.
2. Lisez ce que cela signifie. La date résolue, l'instant en UTC et dans votre propre fuseau, le décalage tel qu'il est écrit, et cette même date exprimée en date ordinale et en date de semaine pour que vous en voyiez les autres écritures.
3. Regardez les trois verdicts. Chaque grammaire indique si elle accepte la chaîne et, dans le cas contraire, quelle règle exactement a été enfreinte. En dessous, votre propre navigateur s'essaie à la même chaîne.

ISO 8601, RFC 3339 et JavaScript sont trois ensembles différents

Ces trois noms s'emploient comme des synonymes, à tort. Nous avons mesuré les trois sur les mêmes chaînes, et aucun n'est un sous-ensemble d'un autre : ils se recouvrent partiellement.

Le Date.parse de JavaScript accepte 2026 et 2026-08, un t et un z minuscules, une espace là où le T devrait être, et un décalage écrit +0200 sans deux-points. Il refuse la forme de base 20260803, la date de semaine 2026-W31-1, la date ordinale 2026-215 et — c'est la plus étrange — une fraction écrite avec une virgule, qui est précisément le séparateur que la grammaire d'ISO 8601 cite en premier. La bibliothèque standard de Python prend presque les décisions inverses : elle accepte la notation de base, les dates de semaine et la virgule, et refuse 2026-08, les minuscules et l'heure 24. Une date ordinale est refusée par les deux, et c'est de l'ISO 8601 parfaitement légal.

La RFC 3339, le profil employé dans les protocoles de l'internet, est la plus stricte des trois et constitue une grammaire normative, non une description. Elle impose le T, impose que le décalage soit présent et écrit en entier sous la forme ±HH:MM, et n'admet que le point avant une fraction de seconde. Elle permet aussi une chose à laquelle les deux autres ne touchent pas : une seconde intercalaire, écrite :60. Ainsi 2016-12-31T23:59:60Z est un horodatage RFC 3339 valide que pratiquement aucune bibliothèque de dates ne sait représenter.

La norme qu'emploie JavaScript est honnête sur sa propre portée. La section 21.4.1.32 d'ECMA-262 décrit son format comme « une simplification du format calendaire étendu d'ISO 8601 », si bien que les dates de semaine, les dates ordinales et la notation de base en sont exclues par conception et non par négligence. Tout ce qui ne correspond pas est laissé, selon les termes de la norme, aux « heuristiques propres à chaque implémentation », et c'est pourquoi l'outil exécute Date.parse dans votre navigateur plutôt que de vous dire ce que font les navigateurs.

Date.parse ne valide pas les dates

Voici le piège qu'il vaut la peine de connaître, et ce n'est pas un défaut des navigateurs : il découle de la norme. Le format JavaScript donne le jour comme « deux chiffres décimaux de 01 à 31 », sans aucune référence au mois. Aussi 2026-02-30 est-elle une chaîne conforme, que les navigateurs interprètent avant de laisser le jour déborder : vous obtenez le 2 mars. En revanche 2026-13-01 renvoie NaN, parce que 13 sort de la plage annoncée pour un mois.

La conséquence est que vérifier une date en demandant si Date.parse renvoie NaN accepte le 30 février, le 31 avril et le 29 février d'une année qui n'a pas ce jour. Cet analyseur les refuse tous, et c'est pourquoi l'un des boutons d'exemple en propose un : collez-le et l'outil vous dira que votre propre navigateur a accepté une date impossible, et vous montrera quelle date il a inventée.

Une seconde surprise, tout aussi prévue, se cache au même endroit. La section 21.4.3.2 d'ECMA-262 énonce que, lorsque le décalage est absent, les formes réduites à une date se lisent comme de l'UTC et les formes date-plus-heure comme de l'heure locale. Ainsi 2026-08-03 vaut minuit UTC, tandis que 2026-08-03T00:00:00 vaut minuit chez vous : ajouter une heure à une date déplace silencieusement l'instant de tout votre décalage, et la même chaîne désigne des moments différents sur des machines différentes. L'outil le signale chaque fois que votre saisie ne porte pas de décalage.

Les formes que presque aucun logiciel n'a vues

Une date ordinale remplace le mois et le jour par le quantième de l'année : 2026-215 est le 215e jour de 2026, c'est-à-dire le 3 août. Une date de semaine numérote la semaine : 2026-W31-1 est le lundi de la semaine 31. La numérotation des semaines obéit à une règle qui surprend — une semaine appartient à l'année qui contient son jeudi, si bien que la première semaine d'une année peut commencer en décembre. 2026-W01-1 est le 29 décembre 2025, et l'outil le signale quand les deux années diffèrent.

La notation de base se contente de retirer les séparateurs, donnant 20260803 et 20260803T120000Z. C'est la forme que l'on croise dans les noms de fichiers, dans les vieux exports de données et dans les blocs EXIF au cœur des photographies, et c'est la raison pour laquelle un nombre isolé de huit chiffres dans un fichier de données est si souvent une date.

Une durée commence par P : P3Y6M4DT12H30M5S vaut trois ans, six mois, quatre jours, douze heures, trente minutes et cinq secondes. L'outil en fait le total en millisecondes, mais seulement quand il le peut. Une durée employant des années ou des mois n'a pas de longueur fixe, puisque sa durée dépend de son point de départ : aucun nombre unique honnête n'existe, et l'outil le dit plutôt que de choisir une moyenne. Un intervalle réunit deux de ces éléments séparés par une barre oblique, selon l'une de trois combinaisons : deux instants, un instant et une durée, ou une durée et un instant.

Ce que cette page ne prétendra pas savoir

ISO 8601 est vendue par l'Organisation internationale de normalisation et n'est pas librement consultable. La grammaire que cet outil vérifie est l'ABNF rassemblée publiée en Annexe A de la RFC 3339, ce qui est ce qui se rapproche le plus d'une version libre et citable — et elle se désavoue avec un certain luxe de détails. Elle porte la mention « informative », elle a été bâtie sur l'édition de 1988, et elle s'ouvre en indiquant qu'ISO 8601 ne définit aucune grammaire formelle.

Elle énumère ensuite quatre points sur lesquels la norme manque de clarté : si la notation de base et la notation étendue peuvent se mélanger dans une même chaîne, si l'heure 24 n'est admise que lorsque les minutes et les secondes valent zéro, si le T peut jamais être omis, et une règle sur la fraction décimale où la section 5.3.1.3 et l'Annexe B.2 de la norme se contredisent franchement. Les auteurs de la RFC ont dû trancher laquelle des deux était fautive. Voilà l'état de l'art d'une norme que tout le monde cite comme si elle réglait la question.

L'heure 24 montre bien à quel point l'accord fait défaut. ECMA-262 l'autorise et ajoute une note affirmant que cela reste cohérent avec ISO 8601 « bien que cette spécification la réserve à la description d'intervalles de temps et ne l'admette pas dans la représentation d'un point unique dans le temps ». L'annexe de la RFC 3339 affirme au contraire qu'ISO 8601 « n'est pas clair » sur ce point et présume que l'heure 24 vaut partout. Deux documents libres décrivant la même norme payante, en désaccord sur ce qu'elle dit.

Enfin, la plage. Les dates JavaScript couvrent environ 273 790 ans de part et d'autre de 1970, et le dernier instant représentable est le 13 septembre 275760. Tout ce qui va au-delà est refusé ici plutôt qu'affiché de travers, car la norme exige que de telles chaînes renvoient NaN sans recourir à la moindre supposition.

Pourquoi est-ce gratuit ?

L'analyse se fait dans votre navigateur. Rien de ce que vous collez n'est envoyé, journalisé ni stocké : fermer l'onglet suffit à tout effacer. Cela compte plus qu'ailleurs ici, car les horodatages qu'on a besoin de déchiffrer sortent le plus souvent de journaux de production et de rapports d'erreur.

Pas de compte, pas d'inscription, aucune limite sur le nombre de chaînes vérifiées, et aucun filigrane sur ce que vous copiez.