Les Timestamps Epoch Expliqués : Comment Fonctionne le Temps Unix (et Pourquoi Il Pose Problème)

Un timestamp epoch — aussi appelé temps Unix ou temps POSIX — est le nombre de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC, sans compter les secondes intercalaires. C'est un entier simple qui représente un instant précis dans le temps, indépendant des fuseaux horaires et des systèmes calendaires. Cette simplicité en fait la façon standard dont les ordinateurs échangent des informations temporelles, mais elle comporte aussi des limitations et des pièges bien connus que tout développeur devrait comprendre.

Comment Fonctionne le Temps Unix

Le temps Unix compte à partir de l'epoch. Un jour équivaut à 86 400 secondes (24 × 60 × 60). Le timestamp augmente exactement d'une unité par seconde, indépendamment du fuseau horaire, de l'heure d'été ou des années bissextiles.

Timestamp 0        → 1970-01-01 00:00:00 UTC
Timestamp 86400    → 1970-01-02 00:00:00 UTC
Timestamp 1000000  → 1970-01-12 13:46:40 UTC
Timestamp 1782000000 → 2026-06-17 00:00:00 UTC

// JavaScript — obtenir le timestamp Unix actuel
const nowInSeconds = Math.floor(Date.now() / 1000);
console.log(nowInSeconds);

// Convertir un timestamp en date
const date = new Date(nowInSeconds * 1000);
console.log(date.toISOString());

// PHP — obtenir le timestamp Unix actuel
echo time();             // secondes depuis l'epoch
echo microtime(true);    // secondes avec précision microseconde

// Convertir un timestamp en date
echo date('Y-m-d H:i:s', 1782000000);

Secondes vs Millisecondes : Une Source Fréquente de Bugs

L'un des bugs les plus fréquents liés aux timestamps est la confusion entre secondes et millisecondes. Date.now() en JavaScript renvoie des millisecondes, tandis que time() en PHP renvoie des secondes. De nombreuses bases de données stockent les timestamps en secondes, et de nombreuses API utilisent les millisecondes.

// ❌ Faux — traiter les millisecondes comme des secondes
const timestamp = 1782000000; // c'est en secondes
const wrongDate = new Date(timestamp); // interprète comme des millisecondes
console.log(wrongDate.toISOString()); // 1970-01-21 — complètement faux

// ✅ Correct — multiplier par 1000
const correctDate = new Date(timestamp * 1000);
console.log(correctDate.toISOString()); // 2026-06-17

import time
from datetime import datetime

# ❌ Faux — oublier de diviser les millisecondes
millis = 1782000000000
wrong = datetime.fromtimestamp(millis)  # ValueError: year out of range

# ✅ Correct
correct = datetime.fromtimestamp(millis / 1000)
print(correct)  # 2026-06-17 00:00:00

Le Problème de l'An 2038

Le temps Unix utilise un entier signé 32 bits, dont la valeur maximale est 2 147 483 647. Le 19 janvier 2038 à 03:14:07 UTC, le timestamp atteindra cette limite. Une seconde plus tard, un entier signé 32 bits passe à −2 147 483 648, ce qui correspond au 13 décembre 1901.

2,147,483,647 → 2038-01-19 03:14:07 UTC (max 32 bits signé)
2,147,483,648 → retour à zéro négatif (débordement)

Systèmes encore vulnérables à Y2038 :

• Systèmes embarqués (routeurs, objets connectés, firmware automobiles)
• Bases de données legacy stockant les timestamps en INT(10)
• Anciens noyaux Linux sur architectures 32 bits
• Systèmes de fichiers utilisant des timestamps 32 bits
• Anciennes versions de PHP sur builds 32 bits

Comment vérifier si un système est compatible Y2038 :

# Linux — vérifier si time_t est 64 bits
getconf LONG_BIT
# 64 → sûr
# 32 → vérifier votre noyau et votre version de libc

# PHP — vérifier la taille des entiers
php -r 'echo PHP_INT_SIZE;'
# 8 → sûr (64 bits)
# 4 → vulnérable (32 bits)

Les systèmes modernes avec time_t 64 bits peuvent représenter des timestamps jusqu'à environ 292 milliards d'années dans le futur, rendant Y2038 sans objet. La plupart des serveurs de production utilisent déjà des systèmes d'exploitation 64 bits, mais les systèmes embarqués et legacy restent à risque.

Les Secondes Intercalaires : La Complexité Cachée

Le temps Unix ignore les secondes intercalaires. Par définition, chaque jour compte exactement 86 400 secondes. Mais le temps astronomique (UT1) nécessite occasionnellement une seconde supplémentaire — une seconde intercalaire — pour rester aligné sur la rotation de la Terre. Lorsqu'une seconde intercalaire se produit, le temps Unix répète la même seconde :

2016-12-31 23:59:59 UTC
2016-12-31 23:59:60 UTC  ← seconde intercalaire (non représentable en temps Unix)
2017-01-01 00:00:00 UTC

La plupart des applications ignorent complètement les secondes intercalaires car elles surviennent de manière imprévisible (généralement une fois tous les 1 à 3 ans) et leur gestion ajoute une complexité significative. Les systèmes qui nécessitent une mesure précise du temps — comme les plateformes de trading financier et les observatoires astronomiques — utilisent le temps TAI (Temps Atomique International) ou le temps GPS plutôt que le temps Unix.

Pièges Courants

Piège 1 : Utiliser la Mauvaise Unité

// L'API renvoie le timestamp en secondes
const apiTimestamp = 1782000000;

// ❌ Faux — new Date() attend des millisecondes
const date = new Date(apiTimestamp);

// ✅ Correct
const date = new Date(apiTimestamp * 1000);

Piège 2 : Stocker en INT(10) dans MySQL

-- ❌ Faux — INT(10) déborde à 2,1 milliards (2038)
CREATE TABLE events (
    created_at INT(10) NOT NULL
);

-- ✅ Correct — utiliser BIGINT ou TIMESTAMP
CREATE TABLE events (
    created_at BIGINT NOT NULL,       -- 64 bits, sûr
    created_at2 TIMESTAMP NOT NULL     -- MySQL gère la conversion
);

Piège 3 : Supposer que l'Heure Locale est par Défaut

// ❌ Faux — date() utilise le fuseau horaire par défaut du serveur
echo date('Y-m-d H:i:s', $timestamp);

// ✅ Correct — spécifier explicitement UTC
echo gmdate('Y-m-d H:i:s', $timestamp);
echo date('Y-m-d H:i:s', $timestamp); // si le TZ par défaut est UTC

Piège 4 : Débordement d'Entier en JavaScript

Les nombres JavaScript sont des flottants 64 bits, mais les opérations bit à bit les traitent comme des entiers signés 32 bits. Cela peut provoquer des bugs inattendus de type Y2038, même sur les navigateurs modernes.

// L'opération bit à bit JavaScript traite en 32 bits
const timestamp = 2500000000; // au-delà du max signé 32 bits
const shifted = timestamp << 1; // ❌ débordement !
console.log(shifted); // -1794967296 (retour à zéro)

Outil de Conversion Epoch

L'outil Convertisseur Epoch / Timestamp Unix sur Help2Code fournit un affichage en direct du timestamp actuel en secondes et millisecondes, une conversion bidirectionnelle entre les valeurs epoch et les dates lisibles, et la prise en charge des fuseaux horaires locaux et UTC. Utilisez-le pour déboguer des problèmes de timestamp, générer des timestamps pour les tests, ou vérifier des réponses d'API. L'outil Convertisseur de Fuseau Horaire est également utile pour vérifier comment les timestamps epoch correspondent à différents fuseaux horaires.

Conclusion

Les timestamps epoch sont une façon simple et universelle de représenter des instants dans le temps, mais ils comportent quelques mises en garde essentielles : vérifiez toujours si vous travaillez avec des secondes ou des millisecondes, utilisez un stockage 64 bits pour éviter le problème Y2038, et ne présumez jamais que le fuseau horaire par défaut correspond à votre intention. Utilisez l'outil Convertisseur Epoch pour des conversions rapides et gardez à l'esprit les directives ci-dessus lorsque vous manipulez des timestamps dans du code de production.