Convertisseur de Dates ISO
Convertit ISO 8601 en Unix epoch, RFC 3339, SQL DATETIME, date semaine et date ordinale avec 4 fuseaux simultanés, temps relatif et seriels Excel/Julian.
À propos du Convertisseur de Dates ISO 8601
Ce convertisseur de timestamp dompte un cimetière de standards de date et heure 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. Voir aussi notre Générateur de Calendrier et notre Calculateur Jours Ouvrables.
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.
Comment convertir un timestamp Unix en date lisible (et inversement) ?
Pour passer d'epoch à date : collez le timestamp Unix dans le champ principal « Entrée de date ». L'outil détecte automatiquement l'unité par grandeur (secondes, millisecondes, microsecondes ou nanosecondes) et rend instantanément l'ISO 8601 étendu, le RFC 3339, le SQL DATETIME et l'heure lisible dans les quatre colonnes de fuseau — ainsi 1747490400 devient 2025-05-17T14:00:00Z. Dans l'autre sens (date → epoch) : collez n'importe quelle date ou chaîne ISO 8601 dans le même champ et lisez les lignes « Unix epoch (secondes) » et « Unix epoch (millisecondes) » du tableau Epoch & seriels ; chaque valeur est dans une boîte de code cliquable pour copier d'un seul geste. Comme secondes et millisecondes diffèrent d'un facteur 1000, confirmez toujours ce qu'attend votre API ou colonne de base de données (to_timestamp() de PostgreSQL et la plupart des fromtimestamp() prennent des secondes ; le Date de JavaScript et Instant.ofEpochMilli() de Java prennent des millisecondes).
Comment calculer le temps exact entre deux dates ou timestamps ?
Mettez le premier instant dans « Entrée de date » et le second dans le champ « Comparer avec » (laissez-le vide pour mesurer par rapport à l'instant présent). La carte Durée exacte affiche alors un delta signé et précis de deux façons : (1) un détail calendaire en années, mois, jours, heures, minutes et secondes calculé avec la vraie longueur des mois — pas une approximation de 30 jours — afin que février et les années bissextiles soient gérés correctement ; et (2) des valeurs totales en jours, heures, minutes, secondes et millisecondes, chacune dans une boîte de code copiable. C'est exactement ce qu'il faut pour les fenêtres de non-respect de SLA, les écarts entre événements de log, l'uptime, les périodes de facturation, les durées de paie et les calculs de « temps jusqu'à l'échéance », sans soustraction d'epoch manuelle. Les deux champs acceptent tout format que l'outil comprend (ISO 8601, Unix epoch, RFC 2822/3339, SQL DATETIME), vous pouvez donc même calculer l'écart entre une valeur en epoch-secondes et une date saisie à la main.
Pourquoi le temps relatif dit « 1 jour » pour une date clairement à 47 heures ?
Le texte de temps relatif tronque (arrondit vers le bas) à la plus grande unité entière — il n'arrondit jamais vers le haut. 47 heures se tronque en « 1 jour », pas 2, car on prend Math.floor(47 / 24) = 1 et on jette les 23 heures restantes. Logique de coupure : sous 60 secondes → « à l'instant » ou « X secondes » ; sous 1 heure → tronquer en « X minutes » ; sous 1 jour → tronquer en « X heures » ; sous 30 jours → tronquer en « X jours » ; sous 1 an → tronquer en « X mois » ; sinon tronquer en « X ans ». Cette troncature délibérée imite l'affichage de l'âge dans les logs et outils CLI (« 1d »), mais elle est lossy par conception. Pour une réponse exacte et non ambiguë, remplissez le champ « Comparer avec » (ou laissez-le vide pour comparer avec maintenant) : la carte Durée exacte affiche le détail calendaire complet (ex. « 1 jour 23h 00m 00s ») plus des totaux copiables en jours, heures, minutes, secondes et millisecondes — sans soustraction manuelle.

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.
