Convertisseur d'horodatage Unix en date

Qu'est-ce qu'un timestamp Unix ?

Un timestamp Unix, aussi appelé Unix time ou POSIX time, est le nombre de secondes écoulées depuis 1970-01-01 00:00:00 UTC, connu sous le nom d'époque Unix. C'est un standard largement utilisé en informatique car il représente un moment dans le temps sous la forme d'un seul nombre entier, ce qui simplifie le stockage, la comparaison et les calculs.

JavaScript fonctionne en interne en millisecondes, donc Date.now() retourne le timestamp Unix multiplié par 1000. Beaucoup d'APIs, de bases de données et de systèmes backend utilisent plutôt les secondes. Cet outil accepte les deux formats et détecte automatiquement les secondes ou les millisecondes en fonction de la taille du nombre saisi.

Timestamps Unix remarquables

Pourquoi 1970 ?

L'époque Unix du 1er janvier 1970 a été choisie en partie par convention et en partie par des contraintes pratiques. Unix a été développé à la fin des années 1960 et au début des années 1970 aux Bell Labs. Les développeurs avaient besoin d'une date de départ récente et arrondie pour leur représentation du temps. Le 1er janvier 1970 était assez récent pour être pratique et n'avait aucune signification technique particulière — c'était simplement un point d'ancrage commode.

D'autres systèmes utilisent des dates d'époque différentes : l'époque FILETIME de Windows est le 1er janvier 1601 ; l'heure GPS a commencé le 6 janvier 1980 ; l'époque NTP est le 1er janvier 1900. Lors de la conversion entre systèmes, connaître l'époque de chaque système est essentiel.

Secondes ou millisecondes

Le timestamp Unix original est en secondes. La plupart des langages côté serveur et des systèmes (shell Unix, time.time() en Python, time() en PHP, la plupart des bases de données) utilisent les secondes. Date.now() et new Date().getTime() en JavaScript retournent des millisecondes. Ce décalage est une source courante de bugs lorsque les frontends JavaScript communiquent avec les APIs backend.

Un timestamp Unix en secondes est actuellement un nombre à 10 chiffres (environ 1 700 000 000 en 2023). Un timestamp en millisecondes est un nombre à 13 chiffres. La calculatrice détecte le format que vous avez saisi en fonction du nombre de chiffres et convertit en conséquence.

Le problème de l'an 2038

Les systèmes qui stockent les timestamps Unix sous forme d'entier signé 32-bit ne peuvent représenter que les dates jusqu'à 2 147 483 647 secondes après l'époque — ce qui correspond à 03:14:07 UTC le 19 janvier 2038. Après ce moment, un entier signé 32-bit déborde en un grand nombre négatif, représentant une date en 1901.

C'est parfois appelé le problème « Y2K38 » ou le Unix Millennium Bug. Les systèmes modernes 64-bit ne sont pas affectés, car un entier signé 64-bit peut représenter des timestamps pendant environ 292 milliards d'années. Cependant, les systèmes embarqués, les bases de données héritées et les anciens logiciels 32-bit peuvent être vulnérables. De nombreux secteurs — incluant les télécommunications, le secteur bancaire et les systèmes de contrôle industriel — mènent des efforts de migration continus pour résoudre ce problème.

Comment obtenir le timestamp Unix actuel

Usages pratiques

Développement d'API : Les APIs REST utilisent couramment les timestamps Unix pour les champs created_at, updated_at et l'expiration de tokens. Un timestamp est indépendant du fuseau horaire et sans ambiguïté — contrairement aux chaînes de date formatées, qui dépendent de la locale et des conventions de formatage.

Expiration de token : JWT (JSON Web Tokens) utilise les timestamps Unix pour les claims exp (expiration) et iat (émis à). Un token expire quand le timestamp actuel dépasse la valeur exp. Calculer les délais d'expiration — « ce token doit expirer dans 24 heures » — nécessite d'ajouter 86 400 secondes au timestamp actuel.

TTL du cache : L'expiration du cache est souvent définie comme un timestamp Unix ou comme un nombre de secondes à partir de maintenant. Le débogage des problèmes de cache nécessite fréquemment de convertir un timestamp d'expiration stocké en une date lisible.

Analyse des journaux : Les journaux serveur incluent souvent des timestamps Unix. Les convertir en dates lisibles est la première étape pour corréler les entrées de journal avec des événements réels.

Stockage en base de données : Stocker les timestamps sous forme d'entiers plutôt que de chaînes formatées évite les bugs de conversion de fuseau horaire et simplifie le tri, les requêtes de plage et les calculs. Une requête pour « tous les enregistrements des 7 derniers jours » devient WHERE created_at > (NOW_UNIX - 604800).