Convertisseur de Dates ISO

À propos du Convertisseur de Dates ISO 8601

Les formats de date et heure forment un cimetière de standards incompatibles : ISO 8601 (formes basique et étendue), RFC 2822, RFC 3339, SQL DATETIME, Unix epoch en secondes / millisecondes / microsecondes / nanosecondes, seriels Excel, Jour Julien, date semaine ISO, date ordinale ISO — et chaque système gère les fuseaux et les secondes intercalaires différemment. Ce convertisseur accepte presque tout (collez, l'outil détecte), puis produit toutes les formes courantes simultanément, avec quatre fuseaux sélectionnables, le jour de l'année, la semaine ISO, le trimestre, le drapeau année bissextile et un texte de temps relatif (« il y a 3 heures », « dans 2 jours »).

Aucun appel réseau, aucun cookie, aucun log — pure arithmétique navigateur contre la base IANA de votre machine. Parfait pour déboguer des logs, tester des contrats d'API, planifier entre équipes et exporter vers des tableurs.

Quelle est la vraie différence entre les formats ISO 8601 « basique » et « étendu » ?

Le format étendu (celui du quotidien) utilise des séparateurs : 2026-05-17T14:30:00.000Z. Le basique les retire : 20260517T143000Z. Information identique ; le basique a été conçu pour des systèmes à jeu de caractères limité (mainframes, codes-barres, noms de fichiers Windows interdisant les deux-points). L'écosystème API moderne préfère universellement l'étendu pour la lisibilité, mais le basique apparaît encore dans le logging industriel, le timecode SMPTE de broadcast et le firmware embarqué. RFC 3339 (le profil HTTP d'ISO 8601) interdit explicitement le basique et exige l'étendu avec « T » ou « » comme séparateur et « Z » ou « +HH:MM » comme fuseau — c'est pourquoi la plupart des API REST aboutissent à 2026-05-17T14:30:00Z.

Comment l'outil détecte-t-il si mon nombre est en secondes, millisecondes, microsecondes ou nanosecondes ?

Par ordre de grandeur. Unix epoch en secondes est un nombre à 10-11 chiffres pour toute date de notre vie (1e9 ≈ 2001, 5e9 ≈ 2128). Les millisecondes ajoutent 3 zéros (1e12 ≈ 2001 en ms). Les microsecondes 3 de plus (plage 1e15). Les nanosecondes encore 3 (plage 1e18). Le parseur vérifie : abs(n) < 1e11 → secondes ; < 1e14 → ms ; < 1e17 → µs ; sinon → ns. Non ambigu pour les dates entre ~1970 et 5000 ap. J.-C. Cas limites : un « 0 » littéral est traité comme secondes (1970-01-01 UTC). Un nombre à 13 chiffres est toujours en millisecondes. Si vous avez un epoch réel à précision seconde à partir de 2086 (>11 chiffres), préfixez d'une clarification — mais ce n'est pas un problème 2026.

Pourquoi le temps relatif dit « dans 2 jours » pour une date clairement à seulement 47 heures ?

Le temps relatif arrondit à l'unité entière la plus proche — 47 heures arrondit à 2 jours parce que l'unité supérieure (jours) est plus proche d'une coupure propre. Logique de coupure : sous 60 secondes → « à l'instant » ou « X secondes » ; sous 1 heure → « X minutes » ; sous 1 jour → « X heures » ; sous 30 jours → « X jours » ; sous 1 an → « X mois » ; sinon « X ans ». Cela correspond aux conventions d'Intl.RelativeTimeFormat utilisées par les navigateurs, notifications d'OS et la plupart des apps de messagerie. Pour l'arithmétique à précision exacte (ex. « combien de minutes jusqu'à ma réunion de 15 h »), utilisez la sortie epoch en secondes et soustrayez.

Qu'est-ce qu'une date semaine ISO et quand l'utiliser ?

Les dates semaine ISO expriment une date sous la forme « année-semaine-jour de semaine » (ex. 2026-W21-3 = mercredi de la semaine 21 de 2026). Deux particularités : (1) les semaines ISO commencent le lundi (pas le dimanche comme aux USA) ; (2) la semaine 1 contient le premier jeudi de l'année — donc 1-3 janvier peuvent appartenir à la semaine 52 ou 53 de l'année ISO précédente. Utilisez pour : systèmes paie/feuilles d'heures (résumés hebdomadaires), planification retail (52 semaines stables/an), grilles broadcast, sprints traitant la semaine comme unité atomique, et tableaux USI montrant « jours depuis l'admission ». Évitez pour la communication humaine (« planifie la réunion pour la semaine 21 » n'a pas de sens sans calendrier).

Les quatre colonnes de fuseau sont-elles synchronisées au même instant ?

Oui — les quatre colonnes rendent le même instant UTC (ce que votre entrée parse), seulement exprimé dans différents fuseaux IANA. Si vous entrez 2026-05-17T12:00:00Z, vous verrez 12:00 en UTC, 05:00 à Los Angeles (UTC-7 DST), 08:00 à New York (UTC-4 DST) et 19:00 à Ho Chi Minh (UTC+7). L'Intl.DateTimeFormat du navigateur gère les transitions DST, les offsets de demi-heure et 45 minutes (Inde UTC+5:30, Népal UTC+5:45) et les changements historiques de règles via la tzdata IANA intégrée. Utile pour planifier entre équipes, corréler des logs entre régions, et vérifier que votre backend écrit des chaînes UTC suffixées Z au lieu de sérialiser accidentellement l'heure locale.

Pourquoi le seriel Excel ne correspond pas à ce qu'Excel affiche sur mon ordinateur ?

Excel utilise deux systèmes de date et la plupart des gens ne le réalisent pas. Par défaut (« système 1900 ») : jour 1 = 1900-01-01, avec le bug fameux où Excel traite 1900 comme année bissextile (elle ne l'était pas) — ajoutant un jour fantôme 60 = 1900-02-29 qui n'a jamais existé. Mac hérité (« système 1904 ») : jour 1 = 1904-01-01. Ce convertisseur sort contre le système Windows 1900 (par défaut pour les nouveaux classeurs) mais compense le bug bissextile en s'ancrant sur 1899-12-30, l'astuce qu'Excel lui-même utilise en interne pour produire des maths correctes pour toute date après 1900-03-01. Si vous travaillez dans un classeur Mac-1904, soustrayez 1462 à notre seriel. Pour vérifier quel système votre classeur utilise : Fichier → Options → Avancé → case « Utiliser le système de date 1904 ».

À quoi sert le Jour Julien et pourquoi est-il décimal ?

Le Jour Julien (JDN) est un comptage continu de jours depuis midi UTC le 1er janvier 4713 av. J.-C. (l'époque julienne proleptique choisie par les astronomes en 1583 car elle précède tout enregistrement historique survivant). La partie décimale est la fraction du jour après midi UTC : .0 = midi, .5 = minuit. JDN domine en astronomie, mécanique orbitale des satellites et arithmétique de dates historiques car il ignore les réformes calendaires (Julien → Grégorien en 1582, non adopté par certains pays jusqu'au XXe siècle). Le JDN d'aujourd'hui est autour de 2 460 829. Le Jour Julien Modifié (MJD) est JDN − 2 400 000,5, plus court et utilisé en télémétrie spatiale et dans les standards CCSDS. Si vous n'êtes pas en astronomie ou aérospatial, vous n'en avez probablement pas besoin — mais les magiciens de tableurs l'utilisent pour des soustractions propres de dates (delta jours = JDN_b − JDN_a).

Comment l'outil gère-t-il les secondes intercalaires et les dates avant 1970 ?

Secondes intercalaires : il ne les gère pas. Unix epoch et l'objet Date de JavaScript ignorent explicitement les secondes intercalaires — chaque jour UTC compte exactement 86 400 secondes. Le vrai UTC a eu 27 secondes intercalaires insérées depuis 1972, donc techniquement il y a un offset d'~27 secondes entre l'UTC affiché et le temps atomique « vrai ». Cela compte pour : GPS, timestamps de marchés financiers (post-MiFID II), mesures scientifiques de haute précision. Cela ne compte pas pour : logs, timestamps d'API, planification, tout ce qui est humain. Pour les dates avant 1970, l'outil les gère — valeurs epoch négatives, dates comme 1066-10-14 (Bataille de Hastings) et av. J.-C. fonctionnent via Date, bien que l'extension grégorienne proleptique signifie que la date affichée peut ne pas correspondre au calendrier julien en vigueur à l'époque. Pour le travail calendaire historique précis, utilisez une bibliothèque d'astronomie dédiée.