Ceci est une ancienne révision du document !
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.
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.
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.
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.
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.
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!