Conversion d'horodatages Unix en ligne, gratuite

Convertissez entre horodatages Unix et dates lisibles.

Aucune donnée ne quitte votre appareil

Horodatage Unix actuel

Horodatage → date

Date → horodatage

Qu'est-ce qu'un horodatage Unix ?

Un horodatage Unix (aussi appelé epoch time ou POSIX time) est le nombre de secondes écoulées depuis le 1er janvier 1970, 00:00:00 UTC. C'est une façon simple et indépendante du fuseau horaire de représenter un instant ; il est largement utilisé en programmation, dans les bases de données, les API et les journaux de serveurs.

Par exemple, l'horodatage 1700000000 représente le 14 novembre 2023 à 22:13:20 UTC. JavaScript utilise des horodatages en millisecondes (multipliez par 1000), tandis que la plupart des autres langages et API utilisent les secondes.

Questions fréquentes

Quels formats de date puis-je saisir ?

Vous pouvez saisir des dates dans la plupart des formats standard : ISO 8601 (2025-12-31T23:59:59Z), chaînes courantes (Dec 31, 2025 11:59 PM), ou formats simples comme 2025-12-31 23:59:59. Le convertisseur utilise l'analyseur de date intégré de votre navigateur.

L'outil détecte-t-il automatiquement secondes et millisecondes ?

Oui. Si l'horodatage dépasse mille milliards, le convertisseur le traite comme des millisecondes ; sinon, comme des secondes. Les deux formats sont affichés dans le tableau des résultats.

Qu'est-ce que le problème de l'an 2038 ?

Les systèmes qui stockent les horodatages Unix sous forme d'entiers signés sur 32 bits déborderont le 19 janvier 2038 à 03:14:07 UTC. Les systèmes modernes utilisent des entiers sur 64 bits, qui peuvent représenter des dates des milliards d'années dans le futur. Cet outil utilise le type Number de JavaScript, qui gère les horodatages bien au-delà de 2038.

Pourquoi le 1er janvier 1970 ?

Un timestamp Unix est un compteur entier de secondes écoulées depuis l'époque Unix, 00:00:00 UTC le jeudi 1er janvier 1970. C'est un scalaire unique qui nomme sans ambiguïté un instant dans le temps, indépendant du calendrier et indépendant des fuseaux horaires, le même nombre désigne le même instant que vous soyez à Tokyo ou à Toronto.

Le choix de 1970 était un peu arbitraire, mais pas aléatoire. La première édition du UNIX Programmer's Manual (novembre 1971) définissait le temps système comme le nombre de tics d'horloge à 60 Hz depuis le 1971-01-01. Avec un entier 32 bits non signé comptant à 60 Hz, le système ne pouvait couvrir qu'environ 2,26 ans avant l'overflow, un problème devenu vite évident. Lors de la préparation de la deuxième édition en 1972, l'équipe de Ken Thompson et Dennis Ritchie est passée au comptage des secondes depuis le 1970-01-01 : des entiers 32 bits signés comptant des secondes tiendraient environ 68 ans, confortablement au-delà de la vie professionnelle des ingénieurs qui écrivaient le code, et le Nouvel An le plus récent avant le début du projet rendait l'arithmétique facile. Il n'y a eu ni vote de comité ni processus de standardisation à la IANA. Le choix est resté parce qu'Unix est sorti avec, et qu'une fois cent millions de machines à compter à partir de cet instant, aucun remplaçant n'était viable.

POSIX (1988) a codifié l'époque 1970 sous IEEE Std 1003.1 comme « Seconds Since the Epoch ». Aujourd'hui, la même époque sous-tend C/C++ time_t, Python time.time(), Ruby Time.now.to_i, JavaScript et Java (en millisecondes, voir ci-dessous), les timestamps de système de fichiers Linux/macOS, les en-têtes de blocs Bitcoin et Ethereum, et les revendications JWT iat/exp/nbf. Quelques systèmes utilisent des époques décalées (Windows FILETIME compte des tics de 100 nanosecondes depuis 1601-01-01, .NET DateTime des tics depuis 0001-01-01), mais le temps Unix est la lingua franca pour tout ce qui traverse une frontière d'OS ou de langage.

Secondes contre millisecondes, le bug le plus fréquent

POSIX définit le timestamp comme des secondes depuis l'époque. Toute lib C, tout interpréteur Python, tout runtime Ruby/Go/Rust/Elixir renvoie des secondes. JavaScript est l'exception célèbre, Date.now() et new Date().getTime() renvoient des millisecondes. System.currentTimeMillis() de Java suit la même convention, et plusieurs systèmes de bases de données plus récents (par exemple le type Date BSON de MongoDB) stockent aussi des millisecondes.

Résultat : un bug inter-langages permanent. Un backend Go écrit 1700000000 (secondes) dans un champ JSON ; un client Node.js passe ça dans new Date(1700000000), mais JavaScript attend des millisecondes, et la date qui en sort est 1970-01-20 au lieu de fin 2023. Le correctif est new Date(1700000000 * 1000). À l'inverse, envoyer un timestamp JS en millisecondes dans datetime.fromtimestamp() de Python donne l'année ~55895. Stack Overflow a des dizaines de variantes de la question « JavaScript Date showing 1970 », et le mismatch est la cause racine dans la grande majorité.

Ce convertisseur applique une heuristique : si l'entrée est supérieure à 1 000 000 000 000, on la traite comme millisecondes ; sinon comme secondes. Ça marche parce que 1e12 secondes correspondrait à l'an 33658 (bien au-delà de toute entrée à l'échelle de la seconde du monde réel), tandis que 1e12 millisecondes est le 9 septembre 2001 UTC (dans la plage moderne). Les timestamps en microsecondes et nanosecondes utilisés par certains systèmes scientifiques et les API du noyau Linux pousseraient le seuil plus haut, pour ceux-là il faudra spécifier la précision explicitement.

Le problème de l'an 2038 (« Y2K38 »)

Un entier signé 32 bits peut stocker des valeurs de −2 147 483 648 à +2 147 483 647. Interprété comme secondes depuis 1970-01-01 UTC, le moment maximal représentable est 03:14:07 UTC le mardi 19 janvier 2038. Une seconde plus tard, le compteur déborde et passe à la valeur la plus négative, qui se décode comme 20:45:52 UTC le vendredi 13 décembre 1901. Tout time_t 32 bits, toute colonne de base qui stocke un entier signé 4 octets pour le temps, et tout système embarqué dont le firmware date d'avant 2010 environ est à risque.

La surface exposée est inconfortable : automates PLC industriels et contrôleurs SCADA avec des cycles de déploiement de 15 à 30 ans installés aujourd'hui ; anciennes colonnes TIMESTAMP de MySQL documentées comme saturant à la limite de 2038 ; systèmes de fichiers ext3 ; formats de protocole binaire (champs RRSIG de DNSSEC, NTPv3, plusieurs bus de terrain industriels) qui empaquètent un timestamp de 4 octets ; smart TV et infodivertissement automobile faisant tourner discrètement d'anciens noyaux Linux 32 bits. Le correctif courant consiste à élargir time_t à 64 bits, ce qui étend le maximum à environ +292 milliards d'années, au-delà de la mort thermique du Soleil. Linux 5.6 (mars 2020) a ajouté les appels système de temps 64 bits à toutes les architectures 32 bits via le patchset y2038 d'Arnd Bergmann ; glibc 2.34 (août 2021) a rendu time_t 64 bits opt-in via _TIME_BITS=64 ; Debian 13 « Trixie » (2025) est la première release avec l'archive entière recompilée. Apple a déprécié les binaires 32 bits dans macOS 10.15 (2019) et iOS 11 (2017), donc le parc grand public est effectivement immunisé.

La surface de risque restante est massivement embarquée et données héritées sur disque : un noyau 64 bits qui lit une colonne de timestamp 32 bits depuis une base de données héritée est tout aussi cassé que la base elle-même. La migration est un problème de format de données par application, pas seulement un problème de noyau.

JavaScript Date, l'API la plus maudite du domaine

L'objet Date de JavaScript a été copié intégralement de Java 1.0 en mai 1995 pendant le sprint de 10 jours que Brendan Eich a passé à écrire le LiveScript original. Java lui-même a déprécié la plupart des méthodes de java.util.Date dans JDK 1.1 (1997), mais JavaScript en a hérité et ne pouvait pas casser la compatibilité web, donc elles restent. Résultat : une API où :

Les mois sont indexés à 0 (new Date(2024, 0, 15) = 15 janvier) mais les jours sont indexés à 1.
getYear() renvoie « l'année moins 1900 », getYear() pour 2024 vaut 124. getFullYear() a été ajouté plus tard pour renvoyer 2024 directement.
Date.parse('2024-03-15') est interprété comme minuit UTC ; Date.parse('2024/03/15') est minuit local ; Date.parse('March 15, 2024') est défini par l'implémentation.
Avant ECMAScript 5 (décembre 2009) le parsing était presque entièrement défini par l'implémentation, la même chaîne d'entrée pouvait donner différentes valeurs Date entre IE, Firefox, Chrome et Safari.

L'API Temporal (TC39 Stage 3 depuis mars 2021) est le remplacement moderne, fournissant Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime et un vrai type Temporal.Duration. Le support navigateur se déploie (Firefox Nightly, Safari 18 partiel, Chrome derrière un flag en 2024) ; les polyfills marchent mais ajoutent ~25 ko. Moment.js a été mis en mode maintenance par ses mainteneurs en septembre 2020, pour les nouveaux projets en 2026 la recommandation est Temporal d'abord si le support navigateur le permet, Luxon ou date-fns sinon, et Moment.js jamais.

Quand vous en avez besoin

Débogage de réponses d'API. La plupart des API JSON renvoient des timestamps soit en entiers Unix soit en chaînes ISO 8601, et beaucoup mélangent. Coller un nombre dans un convertisseur des dizaines de fois par jour est le cas d'usage le plus volumineux.
Analyse de fichiers de logs. syslog, journald, AWS CloudWatch et la plupart des logs applicatifs sont horodatés en secondes Unix. Les ingénieurs copient un timestamp d'une ligne de log et ont besoin de l'équivalent horloge murale.
Inspection de colonnes date en base. Une requête ponctuelle psql ou mysql renvoie 1700000000 ; la base a des fonctions comme FROM_UNIXTIME() mais un outil navigateur est plus rapide pour du travail ad hoc.
Inspection de JWT. Décoder un jeton OAuth montre "exp": 1738367200. Est-il expiré ? Quand expire-t-il ? Un convertisseur de timestamp est la réponse la plus rapide.
Timestamps blockchain. Le nTime de bloc Bitcoin est en secondes Unix (overflow en 2106, 4 octets non signés). Les timestamps de bloc Ethereum sont aussi en secondes Unix.
Métadonnées de système de fichiers OS. ls -l --time-style=+%s imprime les mtime Unix ; stat -c '%Y' filename renvoie mtime en entier. La réconciliation forensique de timestamps passe souvent par un décodage manuel.
Certificat notBefore / notAfter et en-têtes HTTP If-Modified-Since, autant de timestamps qu'il faut décoder de temps en temps.

Une note sur les secondes intercalaires

Depuis 1972, 27 secondes intercalaires ont été insérées dans UTC pour maintenir l'heure murale alignée avec la rotation ralentissante de la Terre. La plus récente était le 31 décembre 2016 23:59:60 UTC. Le temps Unix n'encode pas les secondes intercalaires, POSIX dit explicitement qu'un timestamp Unix prétend que chaque jour fait exactement 86 400 secondes. Les anciens systèmes Linux « répètent » la dernière seconde ; Google et AWS utilisent un « leap smear » qui étale la seconde supplémentaire sur une fenêtre de 24 heures. De toute façon, le temps Unix ne lit jamais 23:59:60 au stockage, et soustraire deux timestamps qui traversent une seconde intercalaire donne une réponse plus courte d'une seconde par rapport au temps écoulé réel en secondes SI. Pour le code applicatif c'est invisible. Pour les logiciels astronomiques ou de trading financier ça peut compter. En novembre 2022, la 27e Conférence générale des poids et mesures a voté pour cesser d'insérer des secondes intercalaires d'ici 2035, les remplaçant par un ajustement périodique bien plus grand.

Aide-mémoire

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's `nTime` limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

Autres questions

Pourquoi le même timestamp affiche-t-il une heure différente sur la machine de mon ami ?

Parce que le nombre sous-jacent est en UTC, mais l'affichage convertit vers l'heure locale. 1700000000 est 22:13:20 UTC, mais 17:13:20 à New York et 06:13:20 le lendemain à Sydney. Le nombre est le même ; seul le rendu diffère. Pour écarter la confusion de fuseaux, demandez aux deux machines d'afficher en UTC.

Quelle est la différence entre Y2K et Y2K38 ?

Y2K (an 2000) était un problème de logique dans le code applicatif : beaucoup de systèmes stockaient les années sur deux chiffres ASCII, donc « 00 » devenait ambigu entre 1900 et 2000. Chaque application devait être inspectée et patchée individuellement ; le coût mondial total de remédiation a été estimé entre 300 et 600 milliards de dollars. Y2K38 est surtout un problème de type de données dans les bibliothèques bas niveau, recompiler la lib C et le noyau contre un time_t 64 bits règle une énorme part de la surface pour toute application qui s'y lie. Les cas durs restants sont les données persistées sur disque (bases de données, métadonnées de fichiers, protocoles binaires) qui demandent du tooling de migration de données. La sagesse conventionnelle est que 2038 sera un événement plus petit et moins médiatique que 2000, plus de pannes localisées d'appareils embarqués, moins de coupures à la une.

Pourquoi new Date('2024-03-15') affiche-t-il parfois le 14 mars ?

Parce que cette chaîne est interprétée comme minuit UTC selon le standard ES5, puis affichée dans votre fuseau local. Dans un fuseau UTC-8 comme US Pacific, minuit UTC le 15 mars correspond à 16 h le 14 mars en heure locale, donc .getDate() renvoie 14. Le correctif en code moderne est soit new Date('2024-03-15T12:00:00') (que JavaScript interprète comme midi local quand vous omettez le Z) soit, mieux, l'API Temporal.PlainDate.from() une fois livrée.

Quelque chose est-il envoyé à un serveur ?

Non. La conversion est de l'arithmétique JavaScript qui tourne en local dans votre navigateur. Rien à propos des timestamps que vous saisissez ne quitte la page, pratique quand les valeurs sont des IDs client, des lignes de log internes ou des données de débogage de session qu'on préfère ne pas téléverser ailleurs. La page fonctionne hors ligne une fois chargée.