ISO 8601 vs RFC 3339 : les deux formats de date derrière vos réponses API

Le champ 'ISO 8601' qui rejette l'ISO 8601 valide — une date de semaine ou une valeur de précision réduite envoyée à une API qui attendait la RFC 3339

Un champ API décrit avec désinvolture comme « ISO 8601 » ne peut accepter qu'une seule forme date-heure. L'envoi d'une autre représentation conforme aux normes peut toujours faire échouer son analyseur. Le remède n’est pas de s’appuyer sur le nom générique ; il s'agit de documenter la grammaire exacte des fils avec des exemples et des tests de validation.

ToolAcre fournit une sortie canonique stable à partir de `Date.toISOString()`, mais ce n'est pas une suite de conformité pour chaque représentation. Traitez la chaîne générée comme un formulaire d'échange utile et comparez-la avec le contrat API que vous possédez réellement.

Un schéma ne doit donc publier une expression régulière ou un type formel que s'il reflète fidèlement l'analyseur. Les exemples seuls sont utiles, mais les cas de rejet explicites mettent fin à l’ambiguïté.

Une norme de date large et une grammaire API étroite ne sont pas interchangeables

Le formulaire généré contient la date du calendrier, `T`, l'heure en millisecondes et le Z final. L'implémentation l'appelle ISO 8601 (UTC) dans l'interface utilisateur. L’entrée accepte ce que lit JavaScript Date, y compris un décalage explicite et la forme date-heure sans zone du sélecteur local.

Ce comportement est beaucoup plus restreint qu'un analyseur standard complet. Les dates de semaine, les intervalles, les durées et la précision réduite n'ont pas de tests de référentiel. Une chaîne acceptée par un navigateur Date n'est donc pas garantie dans toutes les langues, et un formulaire spécialisé rejeté ne réfute pas sa position ailleurs.

La précision fixe en millisecondes de la sortie est un choix de formatage et non une preuve que la source a mesuré les millisecondes. La date a peut-être reçu une valeur d'une seconde entière et imprime toujours `.000`.

ToolAcre émet une forme en forme ISO ; il ne valide pas la norme ISO 8601 complète

Le classeur caractérisait la RFC 3339, son année et ses règles de compensation obligatoires. Aucun texte RFC ou analyseur dédié n'existe dans l'ensemble source, donc ces détails ne sont pas affirmés. Le contrat de rédaction exige de laisser de côté les précisions non étayées plutôt que de citer un titre de mémoire.

Si votre API signifie RFC 3339, nommez-la dans le schéma et testez par rapport à une implémentation fondée sur la spécification réelle. ToolAcre peut relier une époque connue à sa sortie ISO UTC à des fins de comparaison, mais il ne peut pas certifier qu'une entrée arbitraire satisfait ce profil.

Il s'agit d'une protection éditoriale et technique : les profils de normes sont des contrats précis, et les paraphraser sans le texte risque de modifier les exigences de la documentation. Les exigences

RFC 3339 nécessitent une source de normes externe non présente dans ce référentiel

Les allégations concernant les séparateurs alternatifs, les désignateurs minuscules et `−00:00` dépendent du langage exact des normes. Ils sont omis ici. Le propre détecteur de zone du convertisseur reconnaît le Z final ou le `±HH:MM` numérique et signale les dates-heures sans zone comme locales ; c'est la limite que nous pouvons vérifier.

Créez une validation d'API à partir d'exemples explicitement acceptés et de cas de rejet. Ne déduisez pas l’autorisation de l’analyseur pratique de JavaScript Date. Un navigateur permissif peut normaliser les entrées qu'un serveur strict rejette correctement, masquant ainsi les défauts d'interopérabilité lors des tests manuels.

Un analyseur dédié et respectueux des normes doit renvoyer des raisons d'erreur structurées. Laisser Date normaliser une large entrée peut transformer un bug de validation d’API en une divergence multiplateforme ultérieure.

Les règles spécifiques de séparation et de décalage inconnu sont omises sans le texte des normes

Les valeurs d'époque rendent l'arithmétique et la commande compactes lorsque l'unité et l'origine sont fixes. Les dates-heures textuelles rendent une lecture UTC ou offset visible aux personnes et préservent cet indicateur pendant le transport. De nombreuses API choisissent une chaîne canonique pour éviter toute ambiguïté concernant les entiers ou les unités JavaScript.

Si une API contient les deux, définissez quel champ fait autorité et testez l'accord. Une chaîne formatée obsolète à côté d’une nouvelle époque est pire que l’une ou l’autre seule. ToolAcre peut comparer la paire en convertissant l'entier et en vérifiant la valeur ISO générée, mais l'application de la cohérence appartient au producteur.

Exemple concret : un instant, quatre représentations : secondes d'époque, millisecondes d'époque, une chaîne RFC 3339 en UTC et une avec un décalage local

Utilisez l'instant `2025-02-03T10:22:00.000Z`. Ses formes d'époque sont 1,738,578,120 secondes et 1,738,578,120,000 millisecondes. Une lecture de décalage explicite est `2025-02-03T12:22:00+02:00` ; son analyse dans ToolAcre renvoie la même époque et la même ligne ISO UTC canonique.

Il s'agit de quatre représentations vérifiables par le référentiel : secondes, millisecondes, sortie toISOString et une chaîne de décalage numérique analysée par date. L'exemple ne prétend pas que tous les analyseurs externes acceptent la même précision fractionnaire ou la même syntaxe de décalage. Exécutez la propre validation de l’API avant l’expédition.

En soustrayant le décalage +02:00 de l'horloge écrite, on obtient 10:22 UTC. Cette simple égalité suffit pour tester cette entrée particulière sans généraliser une grammaire standard complète.

Exemple concret : un instant dans les quatre formulaires que ce référentiel peut vérifier

Les en-têtes HTTP et les dates d'e-mail utilisent des contrats textuels non implémentés ici. ToolAcre ne formate pas ces protocoles et ne promet pas que sa sortie ISO puisse être remplacée. L’instant d’un horodatage peut être le même alors que sa représentation filaire requise diffère.

Conservez la sérialisation du protocole dans des adaptateurs dédiés avec des appareils copiés à partir de spécifications faisant autorité. Utilisez la conversion d'époque pour vérifier l'instant sous-jacent, puis testez la grammaire séparément. Cela empêche une valeur correcte du calendrier de passer la révision dans une enveloppe syntaxiquement non valide.

L'adaptateur dédié doit également conserver si le décalage manquant ou inconnu comporte une signification de domaine. Aplatir chaque date textuelle dans une hypothèse locale peut détruire cette information.

Les autres protocoles textuels restent en dehors du convertisseur

Spécifiez le format étroit accepté par votre API au lieu de vous fier à une étiquette large. Pour cet outil, la sortie reproductible la plus sûre est la chaîne ISO UTC renvoyée par `toISOString()`, et l'entrée numérique la plus sûre inclut un contrat explicite en secondes ou en millisecondes.

ToolAcre relie ces formulaires et rapporte les hypothèses. Il ne tranche pas tous les cas extrêmes ISO 8601 ou RFC 3339. La propriété claire de la grammaire, de l'unité et du désignateur de zone est ce qui rend les horodatages portables, sans attacher un nom standard familier à un champ sous-spécifié.

Un contrat précis permet aux clients d'échouer tôt avec des messages utiles. Une étiquette large pousse le désaccord dans l'exécution, où deux analyseurs par ailleurs corrects peuvent choisir des sous-ensembles différents.