Vérificateur de portabilité des chaînes de date
Collez une date ou un horodatage (ou un extrait de journal complet) pour voir quelles valeurs seraient interprétées différemment — ou rejetées — par `Date` de JavaScript, Python et d'autres analyseurs courants, et pourquoi.
Traitement effectué localement dans votre navigateur. Votre fichier n’est jamais téléversé.
Comment utiliser cet outil outil
- Collez une date ou un bloc de texte plus long contenant des dates ; rien ne quitte votre navigateur.
- Sélectionnez « Vérifier les dates ».
- Examinez chaque valeur signalée : ce qui la rend ambiguë ou risquée et les environnements qui divergent.
- Utilisez la conversion ISO 8601 proposée lorsqu'elle existe. Certaines ambiguïtés ne peuvent pas être résolues automatiquement ; elles sont expliquées plutôt que devinées.
Hypothèses
- Reconnaît cinq formes précises de date/heure : date-heure ISO 8601 complète (avec ou sans décalage), date simple YYYY-MM-DD (avec ou sans zéros initiaux), date avec tirets et année à deux chiffres, et date séparée par des barres obliques. Dates en langage naturel ("March 3rd"), horodatages Unix et autres formats locaux ne sont pas couverts.
- L'ordre jour/mois d'une date avec barres obliques n'est déduit que lorsqu'il est imposé par les nombres (un élément dépasse 12). Si les deux peuvent être des mois, l'ambiguïté est signalée plutôt que résolue arbitrairement.
- Le siècle correspondant à une année à deux chiffres n'est jamais déduit, même si des conventions courantes existent, car elles varient selon les environnements et bibliothèques.
Sources et données de référence
Méthodologie
Chaque sous-chaîne ressemblant à une date est classée selon sa forme puis comparée aux divergences connues entre `Date` JavaScript, Python et les analyseurs stricts (dont certains moteurs SQL) : minuit implicite UTC ou local pour une date sans heure, interprétation locale ou UTC d'une date-heure sans décalage, déduction du siècle pour les années à deux chiffres et rejet par les analyseurs stricts des éléments sans zéro initial. Une réécriture ISO 8601 sans ambiguïté n'est proposée que lorsque la correction est certaine ; aucune supposition n'est faite.
Exemple détaillé
Date ambiguë séparée par des barres obliques
Données d’entrée: 01/02/2024
Résultat: 1 et 2 sont des mois valides ; selon la convention, cela peut signifier le 2 janvier ou le 1er février. Signalée comme erreur sans conversion automatique : deviner l'ordre serait pire que laisser le problème visible.
Chaîne ISO ne contenant qu'une date
Données d’entrée: 2024-01-15
Résultat: `new Date("2024-01-15")` en JavaScript l'interprète comme minuit UTC, tandis que d'autres langages et la forme `new Date(year, month, day)` de JavaScript interprètent une date nue comme minuit local. À l'ouest d'UTC, le jour calendaire peut donc différer. Le risque est signalé ; la chaîne est déjà ISO 8601 valide et n'est pas convertie.
Date sans zéros initiaux
Données d’entrée: 2024-1-5
Résultat: JavaScript et Python l'acceptent avec souplesse, mais certains analyseurs SQL stricts la rejettent. Conversion sûre en 2024-01-05.
Conseils pratiques
- Ajoutez toujours un décalage UTC explicite (ou "Z") à tout horodatage avec heure qui traverse des systèmes ; c'est le moyen fiable de supprimer l'ambiguïté.
- Ne générez pas d'années à deux chiffres dans le code que vous contrôlez : les règles de déduction du siècle varient, et une année tronquée ne peut pas être corrigée à la lecture.
- Préférez ISO 8601 ("YYYY-MM-DD" ou date-heure complète avec décalage) pour toute date lue par plusieurs systèmes, y compris une autre version de votre propre code.
Erreurs fréquentes
- Prendre l'absence d'erreur d'analyse pour la preuve que la date a été comprise correctement : tous les cas ambigus détectés peuvent être analysés partout, mais donner des valeurs différentes.
- Supposer qu'une chaîne nue "YYYY-MM-DD" est sûre vis-à-vis des fuseaux parce qu'elle ressemble à ISO 8601. Le texte est sans ambiguïté, mais son sens comme instant dépend de la façon dont l'analyseur complète l'heure manquante.
Questions fréquentes
Pourquoi 01/02/2024 est-il une erreur, mais 25/12/2024 seulement une information ?
Dans 01/02/2024, 1 et 2 sont tous deux des mois valides : l'ordre ne peut pas être déduit. Dans 25/12/2024, 25 ne peut pas être un mois, ce qui impose l'ordre jour/mois. Ce n'est pas ISO 8601, mais la date n'est pas ambiguë ; le problème est donc moins grave et peut être converti automatiquement.
Pourquoi l'outil ne suppose-t-il pas que l'année à deux chiffres « 24 » signifie 2024 ?
C'est probable, mais certains systèmes interprètent la même chaîne comme 1924 et d'autres comme 2024, selon leur convention de siècle. L'outil ne devine pas silencieusement lorsqu'une supposition erronée serait pire que l'absence de supposition.
Une date nue comme 2024-01-15 est-elle vraiment risquée ?
Le risque concerne l'instant qu'elle représente lorsque `Date` de JavaScript la lit par rapport à la plupart des autres analyseurs : JavaScript la traite comme UTC, alors que beaucoup de langages la traitent comme heure locale. Comme texte ou donnée stockée, elle est sûre ; le risque apparaît lorsqu'elle est convertie en objet date et qu'on demande quel instant elle représente.
Pourquoi `new Date('2024-01-15')` peut-il afficher la veille ?
ECMAScript interprète la forme ISO date seule à minuit UTC. À l'ouest d'UTC, l'affichage de cet instant en heure locale peut tomber le jour calendaire précédent. Cela diffère de la construction d'un minuit local ou du traitement comme date sans fuseau ; ce vérificateur explique le risque selon la forme, mais n'exécute pas d'autres analyseurs.
Dernière vérification : 2026-09-25
Analyseur limité fondé sur les formes, pas un analyseur de dates complet : reconnaît cinq formes de date/heure précises. Ne détecte ni dates en langage naturel, ni horodatages Unix, ni formats locaux inhabituels. Ne peut pas déterminer la date voulue dans un cas réellement ambigu ; il signale l'ambiguïté.
Les préférences de thème et d’outils, ainsi que les listes enregistrées et récemment utilisées, sont stockées uniquement dans ce navigateur.