Dans vingt-sept ans, le monde informatique rencontrera le Bug de 2038, déjà surnommé Y2K38 par référence au Y2K de 2000. C’est pourquoi aujourd’hui je voulais vous mettre en garde sur les méfaits du Y2K38 ! Il s’agit donc d’un problème similaire au bug de l’an 2000 qui pourrait perturber le fonctionnement d’ordinateurs 32-bits aux alentours du 19 janvier 2038, et plus particulièrement le 19 janvier 2038 après 3h 14min 7s, temps universel. Attention la fin du monde est à nouveau proche…
Historique
En 2000 c’était simple et compréhensible par un enfant de dix ans : les programmeurs avaient été trop négligents ou leurs chefs trop avares pour caser quatre chiffres dans les dates, et il avait fallu tout corriger si on ne voulait pas que notre civilisation s’effondre… Il s’agissait d’un problème de conception et donc de programmation portant sur le format de la date dans les mémoires des ordinateurs et, par conséquent dans les matériels informatiques, ainsi que dans les logiciels. Cette erreur a nécessité dans bien des cas de revoir en profondeur l’architecture des systèmes d’information selon une approche systémique, en particulier lorsque certains composants critiques du système d’information ne pouvaient pas être réparés parce qu’ils étaient trop anciens et n’étaient plus maintenus. Il a donc souvent fallu remplacer complètement des systèmes d’information, généralement spécifiques, par des progiciels du marché compatibles an 2000. Les systèmes plus récents ont pu être réparés par conversion.
Je reste d’avis que la quasi-hystérie de certains milieux sur le sujet est la raison principale qui l’a transformé en non-événement complet. Finalement, aucun problème critique ne s’est produit, et le bug apparaît rétrospectivement comme une fausse alerte. Cependant des sommes considérables ont dû être dépensées pour prévenir tout incident à propos de ce passage.
En 2038 ce sera plus délicat :
- Le concept de date Unix codée en secondes sur 32-bits est nettement plus ésotérique pour n’importe quelle personne
- Le correctif qui consiste à tout recompiler en 64 bits aura été appliqué de manière à peu près universelle d’ici là
- Le bug sera nettement plus complexe à traquer, pas de champ bêtement déclaré comme
ANNEE VARCHAR(2) - Le nombre d’applications, de logiciels embarqués, de puces cachées… aura explosé d’ici là (il n’y a qu’à voir la progression depuis 1978…)
- Les programmes en Cobol qui traînent depuis 30 ans ont dû être corrigés il y a huit à dix ans, sont la preuve vivante de la longévité du nombre de logiciels. Mine de rien, les trois systèmes d’exploitation principaux du moment (DOS/Windows, Unix, Mac OS), même réécrits entre temps, ont des racines qui remontent toutes à plus de 20 ans… Du code qui tournera en 2038 existe donc déjà
Quel est le bug Y2K38 ?
Je ne veux pas être trop alarmiste, mais essayez d’exécuter le code PHP suivant sur votre système :
$date = ‘2040-02-01’;
$format = ‘l d F Y H:i’;
$mydate1 = strtotime($date);
echo ‘<p>’, date($format, $mydate1), ‘</p>’;
[/sourcecode]
Avec de la chance, vous verrez Mercredi 1 Février 2040 00:00 s’afficher dans votre navigateur. Si vous voyez une date dans la fin des années 60 ou début des années 70, votre application PHP pourra être soumis au bug Y2K38 !
Y2K38, ou le bug du millénaire Unix, PHP affecte de nombreux autres langages et systèmes qui utilisent un entier signé sur 32-bits pour représenter les dates comme nombre de secondes depuis le 1er janvier 1970 à 00:00:00 (minuit). La date la plus éloignée qui peut être stockée est le 19 Janvier 2038 à 03:14:07. Au-delà, la représentation du temps « bouclera » (10000000 00000000 00000000 00000000 en binaire) et représentera -2 147 483 648 en complément à deux, et ainsi, l’ordinateur affichera la date du 13 décembre 1901.
Wikipedia : Illustration du phénomène. La valeur décimale de la date deviendra négative à 03:14:08 UTC.
Est-ce que le 64-bits peut nous sauver ?
Probablement. Si vous utilisez un OS 64-bits avec une version PHP compilée elle aussi en 64-bits, votre application ne devrait pas être affectée. Cependant, je vous recommande tout de même la tester. Un nombre signé sur 64-bits donnera une nouvelle date butoir se situant à l’an 292 277 026 596 après J.C. (soit environ 21 fois l’âge de l’univers) et aurait donc résolu le problème, car les 64 bits permettraient à l’ordinateur de pousser la limite à : 263 – 1 secondes.
Vous pouvez probablement dormir sur vos deux oreilles si vous êtes convaincu que votre application sera toujours installée sur un système 64-bits.
Y a-t-il d’autres options ?
Heureusement, PHP a introduit une nouvelle classe DateTime depuis la version 5.2 !
$date = ‘2040-02-01’;
$format = ‘l j F Y H:i’;
$mydate2 = new DateTime($date);
echo ‘<p>’, $mydate2->format($format), ‘</p>’;
[/sourcecode]
La classe DateTime ne souffre pas du problème Y2K38 et elle se fera un plaisir de manipuler des dates jusqu’au 31 Décembre 31,9999. D’ici là grâce à vous lecteur, je serais riche !!! 🙂
Je vous conseille de considérer la classe DateTime lors de vos prochains développements.
Conclusion
« Bah, c’est dans quasiment 30 ans ! A ce moment là les poules auront des dents ! », diront les développeurs de base…
Justement, dans trente ans, rares sont ceux d’entre eux qui seront effectivement à la retraite pour s’en contreficher (tous ceux qui ont moins de 40 ans n’ont pas d’illusions à se faire vues les courbes démographiques…). Et la plupart d’entre eux seront de toute façon encore de ce monde, compte tenue de la progression de l’espérance de vie. Donc forcément concernés.
Mais comptons sur quelques personnes pour remuer la sauce ! Il devrait donc y avoir un pic d’activité des SSII entre 2035 et 2038, mais allez savoir dans quels pays en développement tout cela sera sous-traité à ce moment. Afrique noire ? Chine ? Europe ?
Avez-vous connu le bug Y2K38 dans votre application ? Comment avez-vous résolu ce problème ? Y croyez-vous ?
