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!"
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)
My uptime!
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).
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.
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.
$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.