Slashdot Mirror
You've Got 25 Years Until UNIX Time Overflows
CowboyRobot writes "In 25 years, an odd thing will happen to some of the no doubt very large number of computing devices in our world: an old, well-known and well-understood bug will cause their calculation of time to fail. The problem springs from the use of a 32-bit signed integer to store a time value, as a number of seconds since 00:00:00 UTC on Thursday, 1 January 1970, a practice begun in early UNIX systems with the standard C library data structure time_t. On January 19, 2038, at 03:14:08 UTC that integer will overflow. It's not difficult to come up with cases where the problem could be real today. Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage. Or imagine those phony programs politicians use to project government expenditures, or demographic software, and so on. It's too early for panic, but those of us in the early parts of their careers will be the ones who have to deal with the problem."
those phony programs politicians use to project government expenditures
The programs are real, even if the math may be phony.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
NetBSD has switched to a 64-bit time_t.
Hail Eris, full of mischief...
E pluribus sanguinem
The IOS reminder service will fail for the first week in January atleast once before then :)
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Standing before the steam roller....
"Stoooooooooooooooooooooooooooooooooooooooooooop".... .... "Stooooooooooooooooooooooooooooooooop"....
I understand, we need time to correct the issue, but...c'mon?!
Slow news day?
"Helping to keep you two steps ahead of the Thought Police!"
32bit unsigned, not signed! What'd be the negative timestamps for? Ages before 1970?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
I put in my time working on the Y2K fix. I'll be retired in 5 years, so let the kids of today fix this one. Hell, they need jobs.
Was this a USENET post from '94? Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages. We did not hear an earth-shattering kaboom.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Having a 64-bit will not solve this at all. The problem lie in the software, if a 32-bit time structure as been used, no matter on what computer it's running it will be emulated as a 32-bit application with only 32-bit of memory for time allocation. It will bust, I can see a whole bunch of old program still running because "it work" and company, especially big companies, do not re-write the software in 64 bit.
In terms of personal computers this isn't going to mean much probably by the time it happens. The problem is that there are many, many embedded devices out in the field that are still running with 32-bit time_t vars. Example from a previous job of mine: we made building automation controllers. Those are all devices that are still out in the field and they are all still running old code. Assuming the devices don't die before the time rollover or are not replaced with newer pieces of hardware then it might become a problem.
64bit time will solve it for anything that uses time from the system directly. Meaning all those perl and bash scripts that run so much stuff no one thinks about, from billing to transferring data between companies to scheduling your next vacation are going to be fine.
What will not be fine is crusty old compiled code that was 32bit. Hopefully they are just a recompile away from being fixed. Sadly that is likely not to be the case as generally corporations do not have that kind of foresight.
My uptime!
After all, we handily averted Y2K with decades to spare, and the internet has been migrated to IPv6 for the past ten years. :-P
Time overflowing sounds like a good plot, instead of the usual time repeating, or other cliche time related plots. I'm just curious what the effects of a time overflow would be. *ponders* Maybe a break down in causality?
"Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage."
Well, that's a not-unreasonable example that almost certainly exists already, and seeing as we're only 25 years away - seems like the banks didn't really have any problems with that - at least, none they've advertised.
So the real question is: How big a problem is it really? Application software can trundle off and do what it likes and ignore the clocks it knows are wrong, and 64-bit time systems like are available today are carrying on quite happily.
Y2K was like this - doomsaying about how your mortgage would fail and your wages would stop. Sure, it could - theoretically - have caused problems. But only if your software managers in charge of those things were complete idiots in the first place (and using an app that was written in the 60's, unchanged, isn't an excuse and STILL makes you an idiot).
Y2.038K is definitely MORE of a problem. Definitely. But it's obviously not something that those with software that looks that far ahead are worried about at the moment. And in 25 years, in any of my current computers are still operational I will be incredibly impressed. If any of my computers NEXT YEAR aren't running 64-bit OS (whether or not they have 64-bit clocks) I will be slightly put out! So 25 years to move to 64-bit clocks? No problem.
Why can't you do that with an airliner? Maybe a car, but a car that's still running in 25 years is quite an achievement anyway.
On an airliner? Just basic operational procedure would mean that updates for fixes are common (physical or software) to fix ANY potential problem after YEARS of testing on identical systems deployed in test labs.
There's almost certainly a copy of a Boeing's internals at Boeing where they've done exactly this (e.g. test Y2K rollover to make sure it doesn't affect flightplan or autopilot) and they didn't risk a plane to do so.
25 years means none of your current desktops will still be running (it would be like running a ZX Spectrum as a business machine would be seen today). There might be embedded devices, but how many will go 25 years without a SINGLE test or upgrade or fix or replacement? Very, very, very few.
There isn't a network switch in the world deployed today that will still be around in 25 years untouched. It would literally be like finding out a ZX Spectrum was running vital parts of your business by being tucked away in a cupboard and forgotten about for 25 years and NOT ONE PERSON KNOWING.
If you have a 64 bit PC and OS, it should be little more than a recompile. This is why it's important to have the source.
Give me Classic Slashdot or give me death!
Compiling away isn't always that simple.
You'd be amazed how many people code depending on the fact that sizeof(long) == sizeof(int) == sizeof(void*) == sizeof(time_t) == 4 even when they don't need to and structures are often mapped directly onto binary data, either from disk or network.
I don't actually imagine that 2038 will be much of a problem - most of the issues that will be triggered by the above assumptions will occur between now and then and will be fixed as they occur.
Then 2038 will loom and there will be a big drive to fix everything (else), the magic time will occur and there will be little more than a whimper. Then everyone will complain about the hype about a non-existent problem.
I am quite looking forward to having the option of some lucrative consulting income in my early retirement should I decide I need it. :-)
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
64-bit is taking over already everywhere. In 10-15 years, you will have a hard time finding a 32-bit computer.
The embedded world will still have a lot of 32-bit (as well as 16- and 8-bit) stuff for years to come.
That's where the big problem will be: not with the systems on your desk (or on your lap, or in your pocket), but rather with the hundreds of little CPUs that you don't see (and you may, or may not, be aware of).
Stop warning people! The Unix 32 bit Epoch cleanup is my retirement plan! I'll make a killing fixing legacy software when the kids out of school only know how to point and click through their GUI IDE's and don't know the difference between a short, an int, a long, and a long long... and time_t is completely foreign to them.
I've actually seen some situations close to your example. Imagine 286 desktop machines running Netware 2.X for SAA. It was at a hospital and the only guy that knew anything about them had been dead for almost 6 years. Finally enough of them failed to impact connectivity to the mainframe.
I am quite looking forward to having the option of some lucrative consulting income in my early retirement should I decide I need it. :-)
Then my goal is to thwart your retirement plan. I will contract a low-wage programmer from a yet-to-be-determined developing country to write a piece of software that corrects the issue in any source code and recompiles it for you. I'll sell licenses for $1kUSD a pop, which by 2038 will only be enough to cover the cost of a McDonalds Synthetic Cheeseburger Paste from the Value Menu.
Apparently wizard is not a legitimate career path, so I chose programmer instead.
Not a problem since we'll all be running Windows 11 by then.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
I worked for a DoD contractor in 1999. Our customer had a piece of ground support software for the A-10 that they wanted to make Y2K compliant. Of course, we had to write up a detailed description of the problem and what it might affect so the customer could justify the expenditure to the bean counters. Then we had to write up a preliminary design review to get approval at the high level for what we were going to do. Then we had a critical design review so they could sign off on the detailed implementation of how we were supposed to implement the changes. I based my CDR on the code I had already written to fix the problem. Then I had to put together a testing specification so that we could prove that our date fix didn't destroy the functionality of completely unrelated code. Then we had to go test it on site, do a test report and a final project report.
Nine month project. I don't remember for sure, but I'm pretty sure that the government spent half a million on the entire program. I was the sole technical actor. I changed something like 20 lines of Pascal code, which took me maybe a week or two. I think I spent more time figuring out how to put together their ancient tool chain than writing actual code. Your government dollars at work.
Today's Sesame Street was brought to you by the number e.
Remind me to tag you as "evil bastard" if I ever look at your profile, alright? Not only do you destroy a future old man's retirement scheme, but you turn my stomach with a future menu item. Evil.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
If you have a 64 bit PC and OS, it should be little more than a recompile.
A number of comments have claimed this: recompile with 64-bit time_t and the problem goes away. Unfortunately, for many apps it's not quite as simple as that.
Certainly, for those apps which only deal with time information internally, and in a transient fashion, this will be sufficient to eliminate the problem.
However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol, or basically anything which sends the data structure outside the application is still going to require work on how to handle the migration.
What happens if your app is required to talk on the network? If there are few enough machines involved, then sure, you can upgrade all of them at once, but if it's a large or distributed operation, there needs to be a transition plan. How will older clients and newer clients interoperate?
If data is saved, how will the recompiled application interpret old files? Does it need a way to distinguish them? Can old data be automatically converted? Are there cases where old data may be compromised? (e.g. those 30 year mortgages probably have the wrong end-date stored...) How will we handle those cases?
What about situations where time information is used to prime other calculations - is it okay to affect those other calculations? Serial numbers, PRNGs, UUID generation, etc - the situation has to be assessed. Many cases might be fine, but you can't make a blanket statement for all cases, so each calculation must be vetted.
In the end, the result is that there is work to do. Much of it will be easy to fix, but the assessment still needs to be done.
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Future generations may think we intentionally used these values (e.g. start date and 32-bit signed integer) because we somehow know/predict the Earth will end on this date...
$0.5M to be air-tight sure that a simple 20 lines of Pascal code doesn't crash one (or more) of the hundreds of A-10s in active service, each one worth $12+M, not to mention keeping those pilots safe.
Yes. Definitely our government dollars at work.
You can see why people are extremely reluctant to tinker with man-rated systems.
Don't blame me, I voted for Baltar.
No, that phrase totally means exactly what he things it means, if he's using it in a sales pitch. Anything to support inflating sales and support hours.
Remember, if you're a support contractor or consultant, anything you say means "pay me more."
Welcome to the Panopticon. Used to be a prison, now it's your home.
If you have a 64 bit PC and OS, it should be little more than a recompile.
A number of comments have claimed this: recompile with 64-bit time_t and the problem goes away. Unfortunately, for many apps it's not quite as simple as that.
Certainly, for those apps which only deal with time information internally, and in a transient fashion, this will be sufficient to eliminate the problem.
However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol...
Oh, IPv6 should take care of that.
When our name is on the back of your car, we're behind you all the way!
I would have to be quite a hacker to write code that would crash an A-10. This was for software that displayed actuarial data on engine health, collected by a little computer on the airplane. To get the data, you took a little box out to the airplane, sucked down the actuarial data into the little box, then went back tot the shop and hooked the little box up to the computer that ran the code I had to fix. Even if I was so elite that I could somehow use that software to re-write the code on the little box to somehow instruct it to somehow rewrite the code on the little computer on the airplane, the little computer on the airplane had absolutely no control over anything.
Maybe if I was really, really 1337 I could have gotten it to display "ALL YOUR ACTUARIAL DATA ARE BELONG TO US" instead of the real data, but that's about the most damage I could have done.
Today's Sesame Street was brought to you by the number e.
The regulatory environment and culture of safety that surrounds aviation (military or otherwise) is a remarkable achievement. The complexity of the systems involved is far beyond the capacity of any single human being, even if one aspect of it seems simple or obvious to one observer.
Every time I fly I am happy to have my tax dollars support that framework, even if it occasionally (or frequently) results in unnecessary "red tape." What's the phrase - "procedures only work if you follow them"?
You always have to know the format of a file that you're going to use. Any file with 32-bit time fields will be known as only valid within the 31-bit range +/- January 1, 1970, any data stored with dates outside that range (and that already happens - from bank mortgages to climate change data over millenia) will use appropriate formats - in the same way that you don't store 32-bit image data in a GIF (8-bit colour index) file.
Of course. I was pointing out that data structures don't exclusively reside in memory, and that "just recompile it!" is oversimplifying the solution.
Sometimes these data structures are stored, and sometimes they are dumped straight to a file. Changing the size of an element of a structure that is written to a file will of course change the record sizes and offsets. If you simply "recompile for 64 bit", you may end up reading and writing your data incorrectly.
64-bit time ends on 15:30:08 on Sunday, 4 December 292,277,026,596
you think the programmers in that year will be happy with the mess you left them?
not really planning ahead now are you geniuses?
dear coders of year 292 billion: i'm sorry, we failed you
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Don't talk to me about JSON. JSON does not specify a date/time format at all.
That means the date will be transmitted in some half-assed quote-unquote "format" imagineered by the whimpering skunk fetuses that oh-so-poorly serve as the brains of the inbred sasquatches that are writing the server side.
You'd be amazed at how many programmers don't understand the concept of time zones.
(Invective courtesy of Sodium Eyes.)
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]