Museum boffins find code that crashes in 2037:
A stark warning about the upcoming Epochalypse, also known as the "Year 2038 problem," has come from the past, as National Museum Of Computing system restorers have discovered an unsetting issue while working on ancient systems.
Robin Downs, a volunteer who was recently involved in an exhibition of Digital Equipment Corporation (DEC) gear at the museum, was on hand to demonstrate the problem to The Register in the museum's Large Systems Gallery, which now houses a running PDP-11/73.
The machine's software had already been patched for the Y2K problem, where using two digits to store the year caused headaches when the century rolled around. "Y2K", Downs explained, "was mainly an application programming issue ... mostly it was application programmers not taking into account two digits."
The Year 2038 problem is a different beast. Indicating the PDP-11/73, Downs said, "This machine isn't running Unix, but we have a C compiler on it, and the C compiler is from 1982, so it has ... various issues."
According to Downs, the operating system was patched for Y2K in the late 1990s, but doesn't use the same time structure for its internal date and time.
"So, the C compiler on this, already now, when you ask it what the time and date are, it gets it wrong. It returns the correct time, but the wrong date."
Annoying, but solvable. The team worked around the issue. However, when Downs was testing it by moving the system clock forward, something unexpected happened. He moved the clock forward to 2036, and everything seemed fine.
Then, in 2037 – a year before the Epochalypse is due – the program crashed. "It turns out," said Downs, "the time function has another bug. Undocumented, unknown, where at the start of 2037, any program that calls the time function just crashes."
"So we found bugs that exist, pre-2038, in writing this that we didn't know about."
The Year 2038 problem occurs in systems that store Unix time – the number of seconds since the Unix epoch (00:00:00 UTC on January 1, 1970) in a signed 32-bit integer (64-bit is one modern approach, but legacy systems have a habit of lingering).
At 03:14:07 UTC on January 19, 2038, the second counter will overflow. In theory, this will result in a time and date being returned before the epoch – 20:45:52 UTC on December 13, 1901, but that didn't happen for Downs.
He said, "What we expected was that the local time function should return 1901. That's what we thought would happen."
Instead, it went back to 1970.
[...] Former Microsoft engineer Dave Plummer is optimistic that the problem will be solved in time. He told The Register, "Since the counter starts from current time, anything that is running when it rolls over in 2038 will be suspect. ie: it doesn't have to have been running for long.
"While it's conceivable there are important things that still rely on GetTickCount() or similar, I'd wager the intervening 13 years will be enough to find them!"
(Score: 4, Insightful) by LaminatorX on Tuesday September 02 2025, @02:29PM (3 children)
I'm baffled as to why the researcher expected the clock to go back to 1901 rather than 1970. Rolling the odometer to the dawn of the epoch should be the expected behaviour here.
(Score: 4, Informative) by kolie on Tuesday September 02 2025, @02:47PM
Signed vs Unsigned expected behavior.
(Score: 4, Informative) by ese002 on Wednesday September 03 2025, @05:19AM
It is not rolling over 32 bits. It is rolling into the negative range. The top bit goes to 1 and 30:0= 0, which in 2's complement is -2,147,483,648. 2,147,483,647+1= -2,147,483,648
The fact that it presented 1970 means that some code is taking the extra step to mask the sign bit. It gets very weird if this is not done consistently. Some functions could return 1970 while others think it is 1901.
(Score: 2) by cykros on Thursday September 04 2025, @10:43AM
Yea...just opened this out of my RSS reader to come make sure this got expressed. When counters rollover, they start at 0, not 69 years prior to that.
(Score: 4, Funny) by VLM on Tuesday September 02 2025, @02:43PM (8 children)
Which OS? I skimmed it and we know its not "unix".
Well we know its not PTS-11 because that doesn't have a C compiler LOL.
(Score: 3, Interesting) by looorg on Tuesday September 02 2025, @03:55PM (6 children)
If you are still relying on something such as a PDP-11 or anything sold by DEC I guess you have other issues. Considering the company went out of business almost 30 years ago. Timekeeping might not be at the top of the list of issues for you. Does Compaq even honor any kind of support deals or provide any kind of assistance? Since they bought DEC as far as I can recall now. I doubt that they do.
Question might be does anything critical have issues here? Or is it just that your museum pieces won't do time? Which in turn might break a crapton of other things but still non-production machines and systems. There might be an odd thing here or there but if you are still having these issues, and they can't or won't be fixed during the next 10 years or so. You have problems. But there should still be ample time to fix and migrate away. No worries. I'm sure there will be some absolute panic news in about 10 years time as in regards to this about how it's the end of the world, planes will fall from the sky and power plants will self-combust. Just like at Y2K. Oh right .... We are still here ...
(Score: 4, Interesting) by epitaxial on Tuesday September 02 2025, @04:20PM (1 child)
The machines are still out there and still humming along. https://www.theregister.com/2013/06/19/nuke_plants_to_keep_pdp11_until_2050/ [theregister.com]
(Score: 2) by looorg on Tuesday September 02 2025, @04:40PM
Yickes. Time to Y2K panic then ... or kick that ball down the road for another decade before panicking.
(Score: 2, Touché) by Anonymous Coward on Tuesday September 02 2025, @04:24PM (1 child)
What century do you live in?
HP owns the IP, and gives not two shits about anything DEC any more.
(Score: 2) by VLM on Wednesday September 03 2025, @12:17PM
I think the newer folks are very confused about how things used to be compared to now.
Yes DEC owned RT-11.
However unix v5, v6, v7 and early BSDs were not owned by DEC LOL
(Score: 2) by jb on Wednesday September 03 2025, @06:42AM
The PDP-11 was one of the last computers in which many (most?) faults could still be repaired (rather than just replacing entire subsystems) by anyone with a reasonable background in electronics.
It wouldn't surprise me at all if there still some PDP-11s running decades after the last of today's generation of computers (or even the next generation to come) have long since been scrapped.
(Score: 2) by VLM on Wednesday September 03 2025, @12:33PM
There's about three interesting areas
1) Hobbies are a thing. I'd rather not have one of my toys broken especially if its a minor patch (or if its a major change I better hurry up) Old retro technology stuff is fun and educational.
2) Plenty of things are direct or indirect descendants. Conceivable, although unlikely, that major logic error in dos 1.0 could somehow still be present in windows 11. You see this a lot in security related bugs (which this admittedly probably isn't) like strcpy() can be overly exciting across an industry not just one use case on one OS one time.
3) You can learn from cool / difficult / hard to work on bugs. Often the specific line of code doesn't matter its the interesting process of detecting and isolating the bug thats interesting. A bug thats been "hidden" since 1982 must have an interesting story beyond "it exists and is not on a unix OS".
As for casual research since the original posting of the story, I am somewhat certain this was not a RSTS operating system bug. I know RSX-11 has at least one c compiler I've never even looked at. This might be a story about RSX-11, possibly.
(Score: 3, Funny) by driverless on Wednesday September 03 2025, @09:59AM
I used to work with a Multician who delighted in telling is how Multics was better than anything that came after it. When the Multics source code was released we looked through it and found that it had incorrect date handling that wasn't Y2K safe, and it had been written by said Multician. I'm not sure if we ever had the heart to tell him...
(Score: 1, Interesting) by Anonymous Coward on Tuesday September 02 2025, @03:45PM (7 children)
Museums have been full of machines incapable of supporting the current date since the 70s.
How many 32 bit Unix systems will be in daily use by then?
If you're using a web browser, thanks of Javascript's 64 bit integers and other web BS, anything
32 bits will be a useless boat anchor as a daily driver.
(Score: 3, Interesting) by epitaxial on Tuesday September 02 2025, @04:24PM (4 children)
How many small or embedded systems are out there right now running a 32 bit architecture? Quite a few I'd wager.
(Score: 2) by HiThere on Tuesday September 02 2025, @05:26PM (2 children)
Probably. How many depend on having the correct time? Probably none. Just set the time to zero some time during the next 10 years.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by Snotnose on Tuesday September 02 2025, @07:57PM (1 child)
Lots of embedded systems with small CPUs need the current time. If you're lucky setting the time to 0 will cause obvious problems immediately. If you're like me setting the time to 0 will cause occasional weird oddities that will be very difficult to track down.
Being the dumbest idiot in the land and president of the US should be 2 different people.
(Score: 2) by HiThere on Wednesday September 03 2025, @12:50AM
I'd expect these systems to not be connected to the internet, and have no idea what the actual time is. They just want to keep things in the right order. (Zero is probably the wrong reinit though. 5 or 23 would be better. Or even 1023.) The problem (as I see it) would be if they keep a history...that would need to be cleared.
(And he was working on a PDP11, after all. The same software probably doesn't run on an i8086 or other such. Very few PDP11's are embedded systems.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Interesting) by driverless on Wednesday September 03 2025, @10:05AM
Billions. They're not running Unix though, just using Unix date handling via the C standard libraries. We've (place I work for) had code in our software for at least a decade that checks for time going backwards and other oddities because it's pretty much guaranteed it'll still be running in 2038.
(Score: 4, Informative) by Ingar on Tuesday September 02 2025, @04:38PM (1 child)
64-bit time support on 32-bit Linux was first introduced in the 5.1 kernel.
Love is a three-edged sword: heart, soul, and reality.
(Score: 1) by anubi on Wednesday September 03 2025, @07:12AM
I can't see any reason I can't support 64 bit time even on my eight-bit Arduinos. They already support POSIX right now. If people want it, I can add a 64 bit time type and recompile.
I'll take a small hit on memory and time, as I already do it all eight bits at a time as it stands...as everything I move or store is already denominated as bytes anyway to use the 8-bit interface and communication chips.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 5, Interesting) by Mojibake Tengu on Tuesday September 02 2025, @05:55PM (5 children)
Linux Apocalypse may come sooner than you think:
Linux and Secure Boot certificate expiration
https://lwn.net/Articles/1029767/ [lwn.net]
YMMV.
The kinder you are, the easier it is for wicked people to morally coerce you.
(Score: 3, Interesting) by PinkyGigglebrain on Tuesday September 02 2025, @10:09PM (1 child)
Thanks for the heads up on this.
I don't use UEFI on any of my systems, I don't trust it, but I know people who probably are and when their systems start throwing errors on/after this 11 Sept. I'll know to ask if they are using UEFI.
"Beware those who would deny you Knowledge, For in their hearts they dream themselves your Master."
(Score: 2) by sjames on Sunday September 07 2025, @07:28PM
I do use UEFI, but I disable secure boot. I don't take my desktop machine on the train, and if anyone gets deep enough in to it to install a malicious bootloader, they're deep enough to disable secure boot, re-flash the BIOS, or install their own key, so what would be the point?
That same reasoning probably applies to a lot more machines than it is applied to.
Helpful hint, some BIOS don't have an explicit setting to disable secure boot, but if you delete the key from key management, it turns it off.
(Score: 0) by Anonymous Coward on Wednesday September 03 2025, @01:16AM (1 child)
If true it sounds like a bad design, intentional or not.
I suspect signing + timestamp stuff was already around back then. So perhaps the real truth is it won't be an apocalypse but annoyance?
https://knowledge.digicert.com/general-information/code-signing-certificate-faqs [digicert.com]
https://www.sysadmins.lv/blog-en/digital-signatures.aspx [sysadmins.lv]
If the system already knows the date and time ( in order to know that the certificate has expired) it can know that the timestamp and code should still be valid.
If they did it the timestamp way, old code should still be fine. It's the new code after the expiry date that won't be able to be validated.
So just keep using the old shim. It's not like most of the Linux bunch trust the secure boot stuff anyway right? For them the shim is just to workaround secure boot requirements.
(Score: 1) by anubi on Wednesday September 03 2025, @07:25AM
Stuff like this is exactly why I keep hanging onto my legacy systems. Even the legacy laptops I bought are getting new HDD formatted and partitioned in FAT16 and FAT32 , all MBR, so I can still actually support everything I have ever made. That's about 50 years worth of it. I don't think there are many corporations that can say that.
( Past performance is no indicator for future expectations. I could "go" at any time, and I have not been able to create an environment where I could perpetuate my paradigms. )
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by driverless on Wednesday September 03 2025, @10:09AM
911, it's the best! Hey, my English is getting good. I bet I can count down from five faster than you can!