The 2038 Problem Greetings fellow Sentient Lifeforms. Beaming yet again from somewhere in time and space, I come again to either inspire or bore you. Hopefully it is the former and not the latter. At the end of last month’s article I said… “If you are old enough to remember ‘Y2K’, you’ll be either happy, or scared, to know that in 2038, there will be another one. Hopefully, we will be more ready for that issue than we were back in 1999. We’ll talk about that next month.” Well, now it is next month, and that’s what we’ll talk about. The 2038 problem. But you might not remember Y2K and what it meant to people and the computer industry, so we’ll hop into the Tardis and zip back to 1999 for some perspective first.
Le problème de 2038
Bonjour à tous les êtres vivants sensibles. Venu de quelque part dans le temps et l'espace, je reviens pour vous inspirer ou vous ennuyer. J'espère que c'est le premier cas et non le second.
À la fin de l'article du mois dernier, je disais :
« Si vous êtes assez âgé pour vous souvenir du passage à l'an 2000, vous serez heureux ou effrayé d'apprendre qu'il y en aura un autre en 2038. J'espère que nous serons mieux préparés qu'en 1999. Nous en reparlerons le mois prochain. »
Eh bien, nous sommes le mois prochain, et c'est de cela que nous allons parler, du problème de 2038. Mais vous ne vous souvenez peut-être pas du passage à l'an 2000 et de ce qu'il a signifié pour les gens et l'industrie de l'informatique ; alors, nous allons sauter dans le Tardis et remonter jusqu'en 1999 pour prendre un peu de recul.
What was Y2K Back in the 20th century, when one wanted to write the date, in the US they would write it like “mm/dd/yy” or in the ‘civilized’ world, they would write it “dd/mm/yy” where ‘yy’ was the last two digits of the year . So if they wanted to write a date on a cheque, they would use ‘05/11/64’ or, in the uncivilized US, we would write it ‘11/05/64’. This was something that went back to before the 20th century started. (According to one of my special secret sources, back in the early 1960’s, some people (and software writers) used only one digit for the year!) It wasn’t because people were lazy, it was just that everyone KNEW the century and there was no reason to state the obvious. Once computers started to become popular and part of everyday life, this habit continued. In databases and applications around the world, the habit was maintained. Part of the reason for this was that the cost of memory per kilobyte on disk, ram, and tape (yes, tape) at one point, was over US $100. Think of how much Ram and Hard drive space you have on your home or office computer and then multiply that by 100! When storing date information, those two bytes of memory that hold the ‘19’ would add up and quickly become a stumbling block. It was easy, when needing to print the date on paper or CRT (screen), to just print “19” and then append the two digit year to the end.
De quoi s'agissait le passage à l'an 2000 ?
Au 20e siècle, lorsqu'on voulait écrire la date, aux États-Unis, on l'écrivait « mm/jj/aa » ou, dans le monde « civilisé », « jj/mm/aa », où « aa » représentait les deux derniers chiffres de l'année. Ainsi, pour inscrire une date sur un chèque, on utilisait « 05/11/64 » ou, dans le monde non civilisé des États-Unis, « 11/05/64 ». Cette pratique remonte à bien avant le début du 20e siècle. (Selon l'une de mes sources secrètes, au début des années 1960, certaines personnes (et certains auteurs de logiciels) n'utilisaient qu'un seul chiffre pour l'année !) Ce n'était pas par paresse, mais parce que tout le monde CONNAISSAIT le siècle et qu'il n'y avait pas de raison d'énoncer l'évidence.
Lorsque les ordinateurs ont commencé à devenir populaires et à faire partie de la vie quotidienne, cette habitude s'est poursuivie. Dans les bases de données et les applications du monde entier, cette habitude s'est maintenue. Cela s'explique en partie par le fait que le coût de la mémoire par kilo-octet sur disque, mémoire vive et bande (oui, bande) dépassait à un moment donné les 100 dollars américains. Pensez à la quantité de mémoire vive et d'espace disque dont vous disposez sur votre ordinateur personnel ou professionnel, puis multipliez ce chiffre par 100 ! Lors du stockage des informations relatives aux dates, ces deux octets de mémoire qui contiennent le « 19 » s'additionnaient et devenaient rapidement une pierre d'achoppement. Il était facile, lorsqu'il s'agissait d'imprimer la date sur du papier ou sur un CRT (écran), d'imprimer simplement « 19 » et d'ajouter les deux chiffres de l'année à la fin.
Somewhere around the early 1980s, it dawned on someone just how big a problem this could be. Storing someone’s date-of-birth could show up as 53, but would that be 1853, 1953 or 2653? No way to know. And that was the problem. Anything that stored a date on any kind of computer or computer media, could be a very big problem. So not just date-of-birth but loan payments, school records, driver permits and so on were immediately suspect and the subject of potential problems. However, most of those people in charge of things said “What’s the rush? It’s a long time until the year 2000! We’ll take care of it long before it becomes a problem.” When December 1999 came around, most companies had taken care of it, but there was the lurking concern that while your company had taken care of the issue, how many others out there had not? How many of your vendors or customers had never gotten around to fixing the issue. Luckily, there were only a handful of situations that showed up. However, I remember sitting in Central Texas on December 31, 1999, on emergency call with the company I work for, in Colorado, waiting for the phone to ring with my boss saying that there was a problem with our software because we missed something somewhere that caused our software package to show the date as January 1, 1900.
Au début des années 1980, quelqu'un s'est rendu compte de l'ampleur du problème. L'enregistrement de la date de naissance d'une personne pourrait indiquer 53, mais s'agirait-il de 1853, de 1953 ou de 2653 ? Impossible de le savoir. Et c'est bien là le problème. Tout ce qui stockait une date sur un ordinateur ou un support informatique, quel qu'il soit, pouvait poser un très gros problème. Ainsi, non seulement la date de naissance, mais aussi les remboursements de prêts, les dossiers scolaires, les permis de conduire, etc. étaient immédiatement suspects et sujets à des problèmes potentiels. Cependant, la plupart des personnes en charge de ces questions ont déclaré : « Pourquoi se presser ? Il reste beaucoup de temps avant l'an 2000 ! Nous nous en occuperons bien avant que cela ne devienne un problème. »
Lorsque décembre 1999 est arrivé, la plupart des entreprises s'étaient occupées du problème, mais il y avait une inquiétude latente : si votre entreprise s'était occupée du problème, combien d'autres ne l'avaient pas fait ? Combien de vos fournisseurs ou de vos clients n'avaient jamais pris le temps de régler le problème ?
Heureusement, il n'y a eu qu'une poignée de situations qui se sont présentées. Cependant, je me souviens d'avoir été assis dans le centre du Texas le 31 décembre 1999, en attendant un appel d'urgence de la société pour laquelle je travaille, dans le Colorado, et d'avoir attendu que le téléphone sonne pour que mon patron me dise qu'il y avait un problème avec notre logiciel parce que nous avions oublié quelque chose qui faisait que notre progiciel affichait la date du 1er janvier 1900.
What is the 2038 problem? To quote from Wikipedia, “The problem exists in systems which measure Unix time – the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1970) – and store it in a signed 32-bit integer. The data type is only capable of representing integers between −(231) and 231 − 1, meaning the latest time that can be properly encoded is 231 − 1 seconds after epoch (03:14:07 UTC on 19 January 2038). Attempting to increment to the following second (03:14:08) will cause the integer to overflow, setting its value to −(231) which systems will interpret as 231 seconds before epoch (20:45:52 UTC on 13 December 1901).” https://en.wikipedia.org/wiki/Year_2038_problem With 14 years before this could be a problem, many of the systems that would possibly be affected have already been fixed. The simple fix is not to use a signed integer to hold the number of seconds, but to use a long integer. Operating systems, mainframes, even home computers, are already fixed to avoid this issue.
Qu'est-ce que le problème 2038 ?
Pour citer Wikipedia, « Le problème existe dans les systèmes qui mesurent le temps Unix - le nombre de secondes écoulées depuis l'époque Unix (00:00:00 UTC le 1er janvier 1970) - et le stockent sous la forme d'un entier signé de 32 bits. Ce type de données ne peut représenter que des entiers compris entre -(231) et 231 - 1, ce qui signifie que le temps le plus tardif qui puisse être correctement encodé est 231 - 1 secondes après l'époque (03:14:07 UTC le 19 janvier 2038). Toute tentative d'incrémentation à la seconde suivante (03:14:08) entraînera un dépassement de l'entier et fixera sa valeur à -(231), ce que les systèmes interpréteront comme étant 231 secondes avant l'époque (20:45:52 UTC le 13 décembre 1901). » https://en.wikipedia.org/wiki/Year_2038_problem
Quatorze ans avant que le problème ne se pose, la plupart des systèmes susceptibles d'être affectés ont déjà été corrigés. La solution simple consiste à ne pas utiliser un nombre entier signé pour contenir le nombre de secondes, mais à utiliser un nombre entier long. Les systèmes d'exploitation, les ordinateurs centraux et même les ordinateurs domestiques ont déjà été corrigés pour éviter ce problème.
MicroPython and the 2038 problem While Python and Linux (and I assume Mac and Windows) have all prepared for the 2038 issue, MicroPython (at least up to version RPI_PICO_W-20240509-v1.23.0-preview.360.gc3301da17.uf2) has not. The impact is that when the time and date on the microcontroller reaches 03:14:08 January 19, 2038 UTC, the system will crash with an error “OverflowError: overflow converting long int to machine word”. The Code Shown above. The Output The output in the REPL is shown on the right.
MicroPython et le problème 2038
Alors que Python et Linux (et je suppose Mac et Windows) se sont tous préparés au problème de 2038, MicroPython (au moins jusqu'à la version RPI_PICO_W-20240509-v1.23.0-preview.360.gc3301da17.uf2) ne l'a pas fait.
L'impact est que, lorsque l'heure et la date sur le microcontrôleur atteignent 03:14:08 January 19, 2038 UTC, le système se plante avec une erreur « OverflowError : overflow converting long int to machine word ».
Le code
Voir ci-dessus.
La sortie
La sortie dans le REPL est montrée à droite.
I even put in an issue report on https://github.com/micropython/micropython-lib/issues/842, which (to date, 10 May, 2024) no one has commented on, or as far as I can tell, even looked at it. Wrap up While a large part of me thinks that none of the microcontrollers that we are using today will make it until 2038, I’m pretty sure that a few will, just because they will keep working without problems until then. Hopefully, there is nothing critical running with current code until then. Until next time, as always; stay safe, healthy, positive and creative!
J'ai même rédigé un rapport sur https://github.com/micropython/micropython-lib/issues/842, qui (à ce jour, le 10 mai 2024) n'a fait l'objet d'aucun commentaire ou, pour autant que je sache, n'a même pas été examiné.
Conclusion
Bien que je pense en grande partie qu'aucun des microcontrôleurs que nous utilisons aujourd'hui ne survivra jusqu'en 2038, je suis presque sûr que quelques-uns le pourront, simplement parce qu'ils continueront à fonctionner sans problème jusqu'à cette date. Espérons qu'il n'y aura pas de problème critique avec le code actuel d'ici-là.
Jusqu'à la prochaine fois, comme toujours, restez en sécurité, en bonne santé, positifs et créatifs !