Le timestamp Unix est partout — logs serveur, bases de données, API, JWT — et pourtant source de confusions récurrentes : secondes ou millisecondes ? Quel fuseau horaire ? Ce guide répond à ces questions simplement.
Le timestamp Unix (ou "epoch time") compte le nombre de secondes écoulées depuis un instant de référence fixe : le 1er janvier 1970 à 00:00:00 UTC. C'est une façon de représenter une date et une heure précises sous la forme d'un simple nombre entier, indépendant de tout fuseau horaire, calendrier ou format d'affichage régional.
Cette simplicité en fait le format de référence pour stocker et comparer des dates dans la quasi-totalité des systèmes informatiques : bases de données, langages de programmation, API web, journaux système (logs).
La norme Unix d'origine compte en secondes. Mais de nombreux langages et systèmes modernes (JavaScript, Java) utilisent des timestamps en millisecondes par convention interne — ce qui crée un timestamp 1000 fois plus grand pour représenter la même date.
Un repère simple : un timestamp Unix actuel en secondes compte 10 chiffres (ex: 1735689600), tandis qu'en millisecondes il en compte 13 (ex: 1735689600000). Si le nombre semble anormalement grand pour une date récente, il s'agit probablement de millisecondes.
Confondre les deux est l'erreur la plus fréquente : interpréter un timestamp en millisecondes comme s'il était en secondes donne une date totalement absurde (généralement très loin dans le futur, parfois au-delà de l'an 50000).
Un timestamp Unix ne contient aucune information de fuseau horaire — c'est par définition un nombre de secondes écoulées depuis un instant universel (UTC). La conversion en heure locale (ex: heure de Paris) ne se fait qu'au moment de l'affichage, jamais dans le stockage du timestamp lui-même.
C'est précisément ce qui rend le timestamp Unix si pratique pour les systèmes distribués : deux serveurs dans des fuseaux horaires différents partagent toujours la même valeur de timestamp pour un instant donné, sans ambiguïté possible.
De nombreux systèmes historiques stockent le timestamp Unix dans un entier signé de 32 bits, qui ne peut représenter que des valeurs jusqu'à 2 147 483 647 — ce qui correspond au 19 janvier 2038 à 03:14:07 UTC. Au-delà de cette date, ces systèmes risquent un dépassement de capacité (overflow), faisant revenir le compteur à une date dans le passé (1901), par un mécanisme similaire au bug de l'an 2000.
La plupart des systèmes modernes ont migré vers un entier 64 bits (repoussant le problème à l'an 292 277 026 596), mais du matériel ou des logiciels embarqués anciens restent potentiellement concernés — un sujet de vigilance pour les administrateurs systèmes gérant de l'infrastructure historique.
iat (date d'émission) et exp (date d'expiration) sont des timestamps Unix en secondes.Oui — un timestamp négatif représente une date antérieure au 1er janvier 1970. C'est valide sur les systèmes utilisant un entier signé, mais peut ne pas être supporté par tous les outils ou bibliothèques.
JavaScript (Date.now()) retourne systématiquement un timestamp en millisecondes, contrairement à la convention Unix classique en secondes — c'est une différence à garder en tête lors d'échanges entre un frontend JavaScript et un backend qui attend des secondes.
Non — par convention, le temps Unix ignore les secondes intercalaires ajoutées périodiquement au temps UTC réel pour compenser le ralentissement de la rotation terrestre. Chaque jour Unix est considéré comme faisant exactement 86 400 secondes.
Sur Linux/macOS : date +%s. En JavaScript : Math.floor(Date.now()/1000). En Python : int(time.time()).
Outils similaires