Le problème 2038 des timestamps Unix
Mis à jour : mai 2026
Le problème 2038 concerne les systèmes qui stockent un timestamp Unix signé sur 32 bits. La valeur maximale sera atteinte le 19 janvier 2038 à 03:14:07 UTC.
Gratuit · sans upload · calcul local
La limite
Un entier signé 32 bits peut stocker au maximum 2 147 483 647. Comme un timestamp Unix compte les secondes depuis 1970, cette valeur correspond au 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, un débordement peut ramener la date en 1901.
Systèmes concernés
Les systèmes modernes 64 bits sont généralement protégés. Le risque concerne surtout des systèmes embarqués, vieux noyaux, firmwares, appliances réseau, bases ou formats binaires qui utilisent encore un entier 32 bits pour les dates.
Pourquoi c'est sérieux
Une date qui déborde peut casser des certificats, des planifications, des sessions, des fichiers de logs, des bases historiques ou des systèmes industriels. Le problème est moins visible que le bug de l'an 2000, mais il touche du code plus bas niveau.
Solution
La solution consiste à migrer vers des timestamps 64 bits, des types natifs modernes ou des formats temporels documentés. En base de données, vérifiez le type réel, pas seulement le nom de la colonne.
Test rapide
2147483647 -> 2038-01-19T03:14:07Z
2147483648 -> dépassement possible sur 32 bits signéQuestions fréquentes
Tous les sites web seront-ils cassés en 2038 ?
Non. La plupart des infrastructures modernes utilisent déjà des systèmes 64 bits.
JavaScript est-il concerné ?
Pas directement pour Date, qui utilise un nombre en millisecondes avec une plage beaucoup plus large.
Comment auditer une application ?
Cherchez les champs int32, les APIs C anciennes, les firmwares et les formats binaires qui stockent des timestamps en secondes.