Qu'est-ce qu'un timestamp Unix ? Guide complet avec exemples
Un timestamp Unix est un nombre entier qui représente le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, un instant de référence appelé l’epoch Unix. C’est la façon dont la quasi-totalité des systèmes informatiques stockent une date et une heure en interne, avant de les afficher sous une forme lisible. Le nombre 1700000000, par exemple, correspond au 14 novembre 2023 à 22:13:20 UTC.
Ce qu’est vraiment un timestamp Unix
Concrètement, il s’agit d’un compteur qui avance d’une unité chaque seconde depuis ce point de départ arbitraire de 1970. Pas de mois, pas de jour de la semaine, pas de nom de fuseau horaire, juste un entier qui grandit. 0 correspond à l’epoch lui-même, un nombre négatif correspond à une date antérieure à 1970, et tout nombre positif correspond à un instant après.
Pourquoi les ordinateurs préfèrent-ils cette représentation à une chaîne de caractères du type 14/11/2023 22:13:20 ? Parce qu’un entier est compact, sans ambiguïté et trivial à manipuler. Comparer deux timestamps pour savoir lequel est antérieur revient à comparer deux nombres, pas à parser deux chaînes avec des formats potentiellement différents. Calculer une durée entre deux événements revient à une simple soustraction. Trier une liste d’événements par date revient à trier une liste de nombres. Et surtout, un timestamp Unix ne dépend d’aucun fuseau horaire ni d’aucune langue : 1700000000 veut dire exactement la même chose à Paris, à Tokyo ou sur un serveur situé n’importe où sur Terre. C’est précisément pour ça qu’on le retrouve dans la colonne created_at d’une base de données, dans le champ exp d’un JWT, ou dans chaque ligne d’un fichier de log.
Exemple pratique : lire de vraies valeurs de timestamp
Le tableau suivant donne quelques valeurs de référence, utiles pour se faire une intuition de l’échelle des nombres en jeu.
| Timestamp Unix (secondes) | Date et heure UTC |
|---|---|
| 0 | 1er janvier 1970, 00:00:00 UTC (l’epoch lui-même) |
| 1000000000 | 9 septembre 2001, 01:46:40 UTC |
| 1700000000 | 14 novembre 2023, 22:13:20 UTC |
| 2000000000 | 18 mai 2033, 03:33:20 UTC |
| 2147483647 | 19 janvier 2038, 03:14:07 UTC |
Prenons 1700000000 pour comprendre d’où sort ce 14 novembre 2023. Une année compte environ 31 536 000 secondes (365 jours × 86 400 secondes). Diviser 1 700 000 000 par ce chiffre donne un peu moins de 54 ans après 1970, ce qui vous amène vers la fin de l’année 2023, en ajustant pour les années bissextiles. Vous n’avez pas besoin de faire ce calcul à la main au quotidien, mais ça montre que la logique est purement arithmétique : chaque valeur de la colonne de gauche est un compte de secondes, rien de plus.
Remarquez aussi la ligne 2147483647 : ce n’est pas un hasard si elle tombe précisément en janvier 2038, on y revient plus bas.
Secondes ou millisecondes ? Comment les distinguer
Le piège classique quand on manipule des timestamps : confondre les secondes et les millisecondes. Un timestamp en secondes s’écrit aujourd’hui sur 10 chiffres, comme 1700000000. Le même instant exprimé en millisecondes s’écrit sur 13 chiffres, 1700000000000, tout simplement parce qu’une seconde vaut 1000 millisecondes.
La confusion vient du fait que les deux formats coexistent dans l’écosystème. Date.now() en JavaScript, ainsi que la plupart des API web modernes, retourne des millisecondes. À l’inverse, les appels système Unix, la crontab, et la majorité des outils en ligne de commande sous Linux travaillent en secondes. Si vous collez une valeur en millisecondes dans un champ qui attend des secondes, le résultat n’est pas juste faux, il est absurde : une multiplication par 1000 vous projette dans un futur lointain, potentiellement plusieurs dizaines de milliers d’années après aujourd’hui. C’est un des bugs les plus fréquents (et les plus rapides à repérer) quand une date affichée dans une interface semble complètement délirante.
Convertir un timestamp en date
Vous tombez sur une valeur brute comme celle d’un champ created_at dans une ligne de base de données, ou sur l’horodatage d’une entrée de log, et vous voulez savoir à quel instant réel elle correspond. Collez-la ci-dessous.
Convertir une date en timestamp
Dans l’autre sens, vous connaissez la date et l’heure qui vous intéressent mais vous avez besoin du timestamp correspondant, par exemple pour programmer une tâche cron à un instant précis ou pour construire le corps d’une requête API qui attend un champ numérique. Choisissez la date et l’heure ci-dessous pour obtenir directement la valeur en secondes.
Erreurs courantes et cas particuliers
Confondre secondes et millisecondes. C’est l’erreur numéro un, détaillée plus haut : comptez les chiffres avant de faire confiance à une valeur. 10 chiffres, ce sont des secondes ; 13 chiffres, ce sont des millisecondes.
Le bug de l’an 2038. Les systèmes qui stockent un timestamp Unix sur un entier signé 32 bits atteignent leur limite à 2147483647, soit le 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, le compteur déborde et repart sur une valeur négative, ce qui casse toute la logique de dates basée dessus (des comparaisons deviennent fausses, des durées deviennent négatives). Les systèmes 64 bits modernes n’ont pas ce problème : leur plage de valeurs va bien au-delà de ce qu’on utilisera jamais.
La confusion sur le fuseau horaire. Un timestamp Unix n’a lui-même aucun fuseau horaire, c’est un instant absolu, le même partout sur Terre au même moment. La confusion apparaît uniquement au moment de l’affichage : deux personnes dans deux fuseaux horaires différents qui regardent le même timestamp verront deux heures différentes sur leur horloge locale, mais il s’agit exactement du même instant. C’est pour cette raison qu’un outil de conversion vous montre en général l’UTC en plus de l’heure locale.
Les timestamps négatifs. Une valeur négative représente une date antérieure au 1er janvier 1970 : -86400, par exemple, correspond au 31 décembre 1969. Tous les systèmes ne prennent pas en charge les valeurs négatives, donc si vous manipulez des dates historiques antérieures à 1970, vérifiez d’abord que votre outil ou votre bibliothèque de dates les gère correctement avant de vous y fier.
Questions fréquentes
Qu’est-ce qu’un timestamp Unix ? C’est le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, l’epoch Unix. C’est le format standard utilisé par les systèmes informatiques, les bases de données et les API pour représenter un instant précis sans ambiguïté de fuseau horaire.
Comment savoir si mon timestamp est en secondes ou en millisecondes ?
Comptez les chiffres. Aujourd’hui, un timestamp en secondes compte 10 chiffres (par exemple 1700000000), tandis qu’un timestamp en millisecondes en compte 13 (1700000000000). Si la valeur vous semble représenter une date des années 50000, c’est probablement qu’elle est en millisecondes et que vous l’avez traitée comme des secondes.
Qu’est-ce que le bug de l’an 2038 ?
C’est le débordement qui touche les systèmes stockant un timestamp Unix sur un entier signé 32 bits : la valeur maximale représentable, 2147483647, correspond au 19 janvier 2038 à 03:14:07 UTC. Après ça, le compteur repart en négatif, ce qui casse la logique de dates de ces systèmes. Les systèmes 64 bits actuels ne sont pas concernés.
Peut-on convertir une date antérieure à 1970 ?
Oui, en utilisant un timestamp négatif. Par exemple, -86400 correspond au 31 décembre 1969, un jour avant l’epoch. Toutes les bibliothèques et tous les outils ne gèrent pas les valeurs négatives, donc vérifiez la documentation de celui que vous utilisez avant de vous en servir pour des dates historiques.
Pourquoi les bases de données stockent-elles les dates en timestamp Unix plutôt qu’en chaîne de caractères ?
Parce qu’un entier prend moins de place, se compare et se trie instantanément, et ne dépend d’aucun format régional ni d’aucun fuseau horaire. Stocker 1700000000 élimine tout risque d’ambiguïté qu’on aurait avec une chaîne comme 14/11/2023, qui peut être interprétée différemment selon la locale (jour/mois ou mois/jour) et qui ne dit rien sur le fuseau horaire concerné.