BrowserTools
Publicité
Accueil / Convertisseurs / Convertisseur d'horodatage Unix

Convertisseur d'horodatage Unix

Convertissez entre horodatages Unix et dates lisibles dans n'importe quel fuseau horaire, avec une précision à la milliseconde.

Chargement de Convertisseur d'horodatage Unix… Si rien ne se passe, activez JavaScript.

L'horodatage Unix (Unix timestamp) est un unique nombre entier qui compte les secondes écoulées depuis le 1er janvier 1970, 00:00:00 UTC, un instant connu sous le nom d'époque Unix (Unix Epoch). Ce système a été établi par les premiers développeurs d'Unix aux Bell Labs, car ils avaient besoin d'une manière compacte et neutre vis-à-vis des fuseaux horaires de représenter des instants dans le temps entre des machines en réseau. Le choix de 1970 fut largement pratique : c'était une année récente et ronde qui se situait confortablement dans la plage des entiers de 32 bits, et les premiers systèmes Unix étaient développés à cette époque. Aujourd'hui, l'horodatage Unix est le langage universel du temps pour pratiquement tous les systèmes d'exploitation, bases de données, API et langages de programmation de la planète.

Exemples

Entrée 1700000000
Sortie 2023-11-14 22:13:20 UTC

Secondes de l'époque Unix vers une date UTC lisible.

Entrée 2024-01-01 00:00:00 UTC
Sortie 1704067200

Et inversement : une date UTC vers des secondes de l'époque.

Questions fréquentes

Des données sont-elles envoyées à un serveur lorsque j'utilise cet outil ?
Non. Toutes les conversions s'exécutent entièrement dans votre navigateur en JavaScript. Vos horodatages et vos dates ne quittent jamais votre appareil, ce qui rend cet outil sûr à utiliser avec des données de production sensibles ou des logs privés.
Pourquoi l'époque Unix commence-t-elle le 1er janvier 1970 ?
Le système d'exploitation Unix a été développé aux Bell Labs à la fin des années 1960 et au début des années 1970. Les développeurs avaient besoin d'un point de référence fixe pour la mesure du temps, et 1970-01-01 00:00:00 UTC fut choisi comme un repère commode et récent qui s'inscrivait confortablement dans les contraintes de stockage du matériel disponible à l'époque. Ce fut une décision pragmatique plutôt qu'une décision chargée de sens.
Qu'est-ce que le problème Y2K38 ?
Les systèmes qui stockent les horodatages Unix sous forme d'entier signé de 32 bits ne peuvent représenter que des valeurs jusqu'à 2 147 483 647, ce qui correspond au 19 janvier 2038, 03:14:07 UTC. Après cet instant, l'entier déborde et revient à un grand nombre négatif, ce qui peut faire échouer les calculs de dates. Les systèmes 64 bits modernes ne sont pas concernés, mais les appareils embarqués hérités, les anciennes bases de données et certains systèmes de fichiers peuvent encore être vulnérables.
Quelle est la différence entre les horodatages en secondes et en millisecondes ?
Un horodatage Unix standard est en secondes et comporte 10 chiffres pour les dates de l'ère actuelle (par ex. 1700000000). La méthode Date.now() de JavaScript et de nombreuses API web renvoient des millisecondes, qui ajoutent trois chiffres supplémentaires (par ex. 1700000000000). Cet outil détecte automatiquement le format que vous avez collé d'après le nombre de chiffres, mais vous pouvez le forcer manuellement si nécessaire.
Comment éviter la perte de précision en travaillant avec des horodatages ?
Les nombres à virgule flottante en JavaScript (doubles IEEE-754) ne peuvent représenter en toute sécurité que des entiers jusqu'à 2^53 - 1. Les horodatages en millisecondes restent confortablement dans cette plage pour les dates jusqu'à l'an 275 760, la précision n'est donc pas une préoccupation en pratique. Toutefois, si vous travaillez avec des horodatages d'une précision à la nanoseconde issus de langages comme Go ou Rust, sachez que JavaScript perdra en précision au-delà de 16 chiffres significatifs.
Qu'est-ce que l'ISO 8601 et pourquoi devrais-je l'utiliser ?
L'ISO 8601 est une norme internationale pour représenter les dates et les heures sous forme de chaînes, par exemple 2025-12-31T23:59:59Z. Contrairement aux formats propres à une région, comme 12/31/2025 ou 31.12.2025, l'ISO 8601 est non ambigu, triable en tant que texte brut et compris par l'analyseur de dates de pratiquement tous les langages de programmation. C'est le format recommandé pour les API, les fichiers de logs et l'échange de données.
Puis-je convertir des dates antérieures à 1970 ?
Oui. Les horodatages Unix négatifs représentent des dates antérieures à l'époque. Par exemple, -86400 correspond au 31 décembre 1969, 00:00:00 UTC. C'est entièrement pris en charge par l'outil et par la plupart des environnements de programmation modernes, bien que certains anciens systèmes et bases de données puissent rejeter les valeurs d'horodatage négatives.
Comment fonctionne la conversion de fuseau horaire ?
L'outil utilise l'API intégrée Intl.DateTimeFormat du navigateur avec des noms de fuseau horaire IANA (comme America/New_York ou Asia/Tokyo). Tous les calculs sont effectués en interne en UTC ; le réglage du fuseau horaire n'affecte que l'affichage en sortie. Cela signifie que la valeur de l'horodatage sous-jacent est toujours non ambiguë, quel que soit le fuseau horaire que vous sélectionnez pour la visualisation.
Quelles valeurs d'horodatage vaut-il la peine de mémoriser ?
Quelques repères sont utiles à connaître : 0 correspond au 1970-01-01, 1000000000 (un milliard) était le 9 septembre 2001, 1500000000 était le 14 juillet 2017, et le point de débordement Y2K38 est 2147483647. En millisecondes, Date.now() est toujours un nombre à 13 chiffres commençant par 1 au cours de la décennie actuelle.
Un horodatage Unix inclut-il des informations de fuseau horaire ?
Non. Un horodatage Unix est toujours un décompte de secondes depuis 1970-01-01 00:00:00 UTC et est intrinsèquement indépendant du fuseau horaire. L'information de fuseau horaire est purement une question d'affichage. C'est l'une des principales raisons pour lesquelles les horodatages sont préférés aux chaînes de date formatées pour le stockage et la transmission : ils éliminent toute ambiguïté sur les décalages d'heure locale.

À propos de Convertisseur d'horodatage Unix

Les développeurs rencontrent constamment des horodatages Unix : les jetons JWT portent un champ exp (expiration) en secondes de l'époque, les en-têtes HTTP les utilisent pour le contrôle du cache, les schémas de bases de données stockent les heures des événements sous forme d'entiers pour une indexation rapide, les systèmes d'agrégation de logs comme Elasticsearch indexent les horodatages pour les requêtes par plage, et les applications mobiles synchronisent l'état entre appareils à l'aide de vecteurs de modification basés sur l'époque. Les scientifiques et les analystes de données utilisent les horodatages pour aligner des jeux de données de séries temporelles issus de sources différentes. Même les utilisateurs ordinaires en croisent dans les URL web, les métadonnées de fichiers et les champs d'expiration des cookies, souvent sans s'en rendre compte.

Cet outil convertit entre horodatages Unix bruts et chaînes de date lisibles entièrement au sein de votre navigateur. Aucune donnée n'est jamais envoyée à un serveur. Vous pouvez coller un horodatage de 10 chiffres avec une précision à la seconde ou de 13 chiffres avec une précision à la milliseconde ; l'outil détecte le format automatiquement. Il affiche aussi l'horodatage actuel en direct, vous laisse choisir n'importe quel fuseau horaire IANA dans une liste déroulante avec recherche, et restitue la date à la fois en ISO 8601 et dans un format localisé pour une lecture rapide.

Quelques cas particuliers importants à connaître : l'objet Date de JavaScript travaille en millisecondes, divisez donc toujours par 1000 lors d'une comparaison avec une API basée sur les secondes. Les horodatages négatifs représentent des dates antérieures à 1970 et sont entièrement pris en charge. Le problème Y2K38 est un enjeu qui se profile pour les systèmes qui stockent les horodatages sous forme d'entier signé de 32 bits : de tels systèmes déborderont le 19 janvier 2038 à 03:14:07 UTC, retombant sur une date de 1901. La plupart des systèmes 64 bits modernes y sont immunisés, mais le matériel embarqué et les bases de données héritées peuvent encore être à risque. Lorsque vous travaillez entre fuseaux horaires, stockez et transmettez toujours les horodatages en UTC et convertissez-les en heure locale uniquement pour l'affichage.

Des Bell Labs à chaque appareil sur Terre : l'histoire de l'époque Unix

Le système d'exploitation Unix est né à la fin des années 1960 aux Bell Labs d'AT&T, créé par Ken Thompson, Dennis Ritchie et leurs collègues. Lorsqu'ils ont eu besoin d'un moyen de suivre les heures de modification des fichiers et d'ordonnancer les processus, ils ont conçu le système d'horodatage basé sur l'époque. La date précise du 1er janvier 1970 n'a pas été choisie pour une raison grandiose : c'était simplement un nombre rond proche du moment où le système était construit, et il s'inscrivait bien dans les entiers de 32 bits qui constituaient la limite pratique du matériel de l'époque.

La limite de l'horodatage de 32 bits est à l'origine du problème de l'an 2038, parfois appelé Y2K38 ou le bogue du millénaire Unix. Un entier signé de 32 bits plafonne à 2 147 483 647, ce qui correspond à 03:14:07 UTC le 19 janvier 2038. Après cette seconde, le compteur déborde vers -2 147 483 648, qui correspond au 13 décembre 1901. Les ingénieurs corrigent discrètement ce problème depuis des années : le noyau Linux est passé aux horodatages de 64 bits, et la plupart des bases de données et langages modernes ont suivi. Toutefois, des milliards d'appareils embarqués, de contrôleurs industriels et de systèmes hérités ne recevront peut-être jamais de mises à jour.

JavaScript a repris le concept d'époque et l'a multiplié par 1000, travaillant en millisecondes plutôt qu'en secondes, car le langage a été conçu pour des interfaces web interactives où la temporisation infraseconde compte. C'est pourquoi Date.now() renvoie un nombre à 13 chiffres. D'autres langages ont fait des choix différents : time.time() de Python renvoie une valeur de secondes en virgule flottante, time.UnixNano() de Go travaille en nanosecondes, et les bases de données SQL stockent souvent les horodatages sous forme de chaînes formatées, le tout se référant au même concept sous-jacent que deux programmeurs ont improvisé aux Bell Labs il y a plus d'un demi-siècle.

Publicité
Publicité
Publicité