Les timestamps Unix expliqués : conversion et pièges courants

Un timestamp Unix est l'un des concepts les plus simples mais les plus mal compris en programmation. C'est le nombre de secondes écoulées depuis le 1er janvier 1970, 00:00:00 UTC — un moment connu sous le nom d'epoch Unix. Malgré sa simplicité, les timestamps sont une source de bugs liés aux fuseaux horaires, à la précision et au dépassement de capacité.

Qu'est-ce que l'epoch Unix ?

L'epoch Unix — 1er janvier 1970, 00:00:00 UTC — a été choisi comme point de départ du temps Unix. Chaque timestamp est mesuré par rapport à ce moment :

Les timestamps négatifs représentent des dates avant l'epoch. Par exemple, -86400 correspond au 31 décembre 1969.

Convertissez les timestamps instantanément avec notre Convertisseur de timestamps.

Secondes vs. millisecondes

C'est la source de confusion la plus courante. Différents systèmes utilisent différentes précisions :

Règle empirique : Si le nombre a 13 chiffres, ce sont des millisecondes. S'il a 10 chiffres, ce sont des secondes.

// JavaScript returns milliseconds
const nowMs = Date.now();          // 1700000000000
const nowSec = Math.floor(nowMs / 1000);  // 1700000000

Gestion des fuseaux horaires

Les timestamps Unix sont toujours en UTC. Ils ne contiennent pas d'information de fuseau horaire. C'est en fait un avantage — cela fournit un point de référence universel.

La confusion survient lors de la conversion des timestamps en dates lisibles :

const ts = 1700000000;
const date = new Date(ts * 1000);

date.toUTCString();      // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString();    // Depends on user's local time zone
date.toISOString();       // "2023-11-14T22:13:20.000Z"

Bonne pratique : Stockez et transmettez les timestamps en UTC. Convertissez en heure locale uniquement au niveau de l'affichage, au plus près de l'utilisateur.

Le problème de l'an 2038

Les systèmes Unix traditionnels stockent les timestamps comme un entier signé 32 bits. La valeur maximale est 2 147 483 647, ce qui correspond au 19 janvier 2038, 03:14:07 UTC.

Après ce moment, les timestamps 32 bits débordent vers des valeurs négatives, revenant au 13 décembre 1901. C'est analogue au bug de l'an 2000.

État actuel :

• La plupart des systèmes modernes utilisent des timestamps 64 bits (valables jusqu'à l'an 292 milliards)
• Le noyau Linux est compatible timestamps 64 bits depuis la version 5.6 (2020)
• Les systèmes embarqués et les bases de données héritées restent à risque
• Si vous construisez un logiciel qui gère des dates au-delà de 2038, vérifiez votre stockage de timestamps

Conversion dans différents langages

JavaScript

// Current timestamp (seconds)
const now = Math.floor(Date.now() / 1000);

// Timestamp to Date
const date = new Date(1700000000 * 1000);

// Date to timestamp
const ts = Math.floor(new Date('2023-11-14').getTime() / 1000);

Python

import time, datetime

# Current timestamp
now = int(time.time())

# Timestamp to datetime
dt = datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc)

# Datetime to timestamp
ts = int(dt.timestamp())

SQL (PostgreSQL)

-- Current timestamp
SELECT EXTRACT(EPOCH FROM NOW());

-- Timestamp to date
SELECT TO_TIMESTAMP(1700000000);

-- Date to timestamp
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);

Pièges courants

1. Mélanger secondes et millisecondes

Si une date affiche janvier 1970, vous avez probablement passé des secondes là où des millisecondes étaient attendues (ou inversement). Vérifiez toujours quelle précision l'API attend.

2. Ignorer les fuseaux horaires dans les chaînes de dates

Parser "2023-11-14" sans fuseau horaire crée la date dans le fuseau horaire local, qui varie selon l'emplacement du serveur. Incluez toujours le fuseau horaire : "2023-11-14T00:00:00Z".

3. Précision en virgule flottante

Lors du stockage de timestamps en nombres à virgule flottante, vous pouvez perdre de la précision au-delà des millisecondes. Pour une précision en microsecondes ou nanosecondes, utilisez des entiers avec le multiplicateur approprié.

4. Secondes intercalaires

Les timestamps Unix ne tiennent pas compte des secondes intercalaires. Un jour Unix fait toujours exactement 86 400 secondes, même si les jours UTC réels ont occasionnellement 86 401 secondes. Pour la plupart des applications, c'est sans importance. Pour les applications scientifiques ou satellitaires, utilisez le TAI (Temps Atomique International) à la place.

ISO 8601 : l'alternative lisible

Bien que les timestamps soient excellents pour les calculs, ISO 8601 est le standard pour la représentation lisible des dates :

2023-11-14T22:13:20Z          # UTC
2023-11-14T17:13:20-05:00     # Eastern Time
2023-11-14                     # Date only

La plupart des API devraient accepter et retourner des chaînes ISO 8601. Utilisez les timestamps en interne pour les calculs et le stockage.

FAQ

Pourquoi le temps Unix commence-t-il le 1er janvier 1970 ?

La date a été choisie de manière arbitraire lorsque Unix était en cours de développement aux Bell Labs au début des années 1970. Une date suffisamment récente était nécessaire pour éviter de gaspiller des bits sur des dates du passé lointain. Comme les entiers 32 bits peuvent stocker environ 68 ans dans chaque direction, commencer en 1970 couvrait les dates de 1901 à 2038.

Dois-je stocker les dates comme timestamps ou comme chaînes formatées dans ma base de données ?

Stockez les dates comme timestamps (entier ou types datetime natifs) pour un tri, une comparaison et une arithmétique efficaces. Les chaînes formatées sont plus difficiles à interroger et à trier correctement. La plupart des bases de données ont des types datetime natifs qui gèrent bien cela. Réservez le formatage en chaîne pour l'affichage et les réponses API.

Ressources associées

• Convertisseur de timestamps — Convertissez entre timestamps Unix et dates lisibles
• Bonnes pratiques de formatage JSON — Gérer les dates dans les réponses JSON
• Guide des UUID — Un autre format d'identifiant courant avec des variantes basées sur le temps