Le problème de l'an 2038 (Y2K38) expliqué

Qu'est-ce que le bug de l'an 2038 ?

Les timestamps Unix sont traditionnellement stockés sous forme d'entier signé 32 bits comptant les secondes depuis le 1er janvier 1970 00:00:00 UTC. La valeur maximale d'un entier signé 32 bits est 2,147,483,647, ce qui correspond au 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, l'entier déborde à -2,147,483,648. Interprétée comme timestamp Unix, cette valeur négative correspond au 13 décembre 1901, renvoyant les systèmes concernés près de 137 ans dans le passé.

Les valeurs du dépassement

• 2^31 − 1 = 2,147,483,647 (entier signé 32 bits maximal)
• 2,147,483,647 en date = 19 janvier 2038 03:14:07 UTC
• 2,147,483,647 + 1 déborde à −2,147,483,648 (la valeur 32 bits la plus négative)
• −2,147,483,648 en date = 13 décembre 1901 20:45:52 UTC

Quels systèmes sont à risque ?

Le problème touche les systèmes qui stockent les timestamps en entiers signés 32 bits :

• Systèmes embarqués et microcontrôleurs avec time_t 32 bits
• Code C et C++ hérité compilé pour des cibles 32 bits utilisant time_t ou int pour les timestamps
• Anciens noyaux Linux (avant 5.6) sur matériel 32 bits encore en production
• Colonnes TIMESTAMP de MySQL — limitées au 2038-01-19 ; utilisez DATETIME à la place
• Certains protocoles réseau et formats de fichier qui encodent les timestamps sur 32 bits
• Firmware de systèmes de contrôle industriel et d'objets IoT à durée de vie de plusieurs décennies

Quels systèmes sont sûrs ?

La plupart du code et des infrastructures modernes ne sont déjà plus concernés :

• Tout OS 64 bits — Linux (glibc 2.34+ corrige aussi le matériel 32 bits), macOS, Windows
• Python — les timestamps utilisent des floats 64 bits, sûrs bien au-delà de l'an 292 millions
• JavaScript — Date utilise des floats IEEE 754 64 bits, sûr jusqu'à l'an 275,760
• Go et Rust — utilisent int64 en interne, sûrs pour des milliards d'années
• Java — java.time.Instant utilise long (64 bits), sûr jusqu'à l'an ~292 millions
• PostgreSQL TIMESTAMP — stocke correctement les dates au-delà de 2038
• MySQL DATETIME — plage 1000-01-01 à 9999-12-31, non concerné

FAQ sur le bug de l'an 2038

Qu'est-ce que le bug de l'an 2038 ?

Le bug de l'an 2038 (Y2K38) est un défaut par lequel les systèmes utilisant des entiers signés 32 bits pour stocker les timestamps Unix déborderont le 19 janvier 2038 à 03:14:07 UTC. La valeur maximale d'un entier signé 32 bits est 2,147,483,647. Une seconde plus tard, l'entier bascule à -2,147,483,648, ce qui correspond au 13 décembre 1901.

Quel est le timestamp Unix du 19 janvier 2038 ?

Le timestamp Unix du 19 janvier 2038 à 03:14:07 UTC est 2,147,483,647, la valeur maximale d'un entier signé 32 bits (2^31 - 1). C'est le moment exact où survient le dépassement de l'an 2038 sur les systèmes 32 bits.

Y2K38 est-il identique au Y2K ?

Non. Le Y2K (bug de l'an 2000) venait de programmes stockant les années sur 2 chiffres. Le Y2K38 vient du stockage des timestamps Unix en entiers signés 32 bits qui débordent en 2038. Causes différentes, systèmes touchés différents.

Internet va-t-il tomber en panne en 2038 ?

Probablement pas de façon majeure. L'essentiel de l'infrastructure internet a déjà migré vers des systèmes 64 bits. Le risque se concentre sur les systèmes embarqués, les objets IoT anciens et les logiciels non mis à jour depuis des décennies. Les OS, langages et bases de données modernes sont déjà sûrs.