You've Got 25 Years Until UNIX Time Overflows 492
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."
Could we be a little less biased? (Score:5, Insightful)
those phony programs politicians use to project government expenditures
The programs are real, even if the math may be phony.
Re:Could we be a little less biased? (Score:5, Insightful)
History shows us that it's not biased in the slightest to assume that politicians will lie, cheat, and steal their way to riches. Giving them the benefit of the doubt is like Charlie Brown giving that field goal one more shot because maybe, just maybe, Lucy won't pull the ball this time.
Re: (Score:3)
Most Insightful Post Ever!
Re: (Score:2, Funny)
History shows us that
Blah blah blah. The parent was not giving anyone the benefit of the doubt. And just FYI the whole football thing was an analogy for sex.
As for the article, I'll sum it up for everyone: "Y2K is coming to get youuuuuuuuuuuuuuuuuu!!!! Hide the children!"
Re:Could we be a little less biased? (Score:4, Funny)
...And just FYI the whole football thing was an analogy for sex....
And anyway, Peter Griffin took care of that football thing once and for all.
Re: (Score:3)
Re:Could we be a little less biased? (Score:4, Insightful)
You would think that if all politicians cared about was their own greed, they'd be far better off than they are now no?
Re:Could we be a little less biased? (Score:5, Insightful)
We denigrate politicians because they lie, but candidates who tell the truth do not get elected.
Re:Could we be a little less biased? (Score:5, Insightful)
History shows us that it's not biased in the slightest to assume that politicians will lie, cheat, and steal their way to riches.
What is biased is to assume that the non-elected civil servants who actually do the math will not attempt to do their jobs to the best of their ability. For example, the staff at the Congressional Budget Office who actually do the math do not directly report to any politician. Similarly, the civil service laws exist specifically to prevent someone from, say, being fired by NOAA for coming up with the "wrong" climate data, or fired from the SSA for coming up with the "wrong" Social Security budget projections.
So you're right to assume that politicians lie, cheat, and steal. But that doesn't mean that a GS-11 actuary working in the bowels of a government agency is lying in his reports.
Re: (Score:3)
Have you worked in "the trenches" in those sectors before.
(1) You may not be able to be fired for those reasons, but most employers can easily find other reasons to fire an employee. So there's still that fear. It doesn't happen /just/ in Corporate America.
(2) Even if you aren't directly/indirectly reporting to a political figure, they still pull enough strings to make you worry, and they can still exert influence outside of the chain of command.
It's not a cut and dry situation. There are buffers, but none
Re: (Score:3)
And the report they come up with will say something along the lines of "Here are the assumptions that Congressman Blowhard requested we used: ..." They will sometimes also say "Here are the assumptions that Congressman Blowhard requested we used: ... Here's what we think is actually a realistic projection: ..."
The CBO didn't lie: Their report said exactly what assumptions were made, what the conclusions were going to be if those assumptions were made, and hinted that the assumptions weren't valid. What hap
Re:Could we be a little less biased? (Score:5, Informative)
Actually, banks, and such already ran into Y2K problems in the 70s when long term loans starting overflowing them. For them the Y2K scenario had many years to be fixed slowly (mostly a continuous updating thing - as things broke, they fixed it) so there was no big rush for them as they were experienced in such issues.
If there are any 2038 issues, the banks have already been ahead of the curve and seeing them in 2008. Hell, a good conspiracy theory....
time_t has also been 64 bit for a number of years now (you don't need a 64-bit system to deal with 64-bit numbers - it's just dealing with them is a lot slower as the compiler emits library calls to perform the arithmetic). So it's not a real problem even on embedded systems (ARM only added 64-bit support in the ARMv8 instruction set - and only in the high-end A (applications) profile processors - the lower end R (real-time) and M (microcontroller) profiles are still ARMv7 only).
However, even those compiled with 64-bit time_t aren't necessarily safe - you'd probably find most of them assume it's still a 32-bit quantity and end up storing it as such - ignoring the compiler warnings or casting to get rid of them. So even programs of today with 64-bit time_t's won't necessarily make it past 2038 either.
And if stuff like that is done, recompiling does diddly - the bug will still strike despite a 64-bit everything. Hell, someone may have decided during the conversio nto increase the timestamp size from 32 to 64 bit, but didn't realize someone squashed it down to 32-bit upstream.
Re:Could we be a little less biased? (Score:4, Insightful)
you don't need a 64-bit system to deal with 64-bit numbers - it's just dealing with them is a lot slower as the compiler emits library calls to perform the arithmetic...
A lot slower? Nah. Negligble, at best. It'll be fine.
Re:Could we be a little less biased? (Score:4, Insightful)
If you're doing so many 64-bit calculations that it's seriously impacting the performance of your 32-bit machine, then either you don't care or you need to upgrade to a 64-bit machine.
I'm sure you can come up with a scenario where that's not possible, but I see no reason to solve that problem until and unless it comes up. Meantime, I do all my work on 8-bit processors and laugh at your 64-bit woes (somewhat hysterically).
Re: (Score:3)
depends.
If a system has 32 bit words, but handles 64 bit nubmers (i.e. starting somewhere in the i386-i586 range? of x86), it's negligably slower. If, however, it has to be emulated via the use of 2 32 bit nubmers...
Then at minimum, you need to perform the op twice. Then there's overflow checking and handling, 2 more ops, one of which is a branch... or if neither is a branch, the branch will be a third op.
Not in C, there isn't.
so 4-5 ops instead of one, one of which would be a branch.
Re:Could we be a little less biased? (Score:5, Funny)
For them the Y2K scenario had many years to be fixed slowly (mostly a continuous updating thing - as things broke, they fixed it) so there was no big rush for them
There's a motorcycle shop in my town where all the receipts are dated "1913". And printed with tractor feed dot-matrix.
So not everybody's in a big hurry.
Re:Could we be a little less biased? (Score:5, Interesting)
I've seen some relatively new systems using a 32-bit time, even some using the same API as Unix. It's relatively common in embedded systems. Many of them just go ahead and use signed 32-bit as there's no need to have internal times be compatible with external systems.
Ultimately I think the problem arises because of overusing time_t. Originally this was something you used to attach a time to a file in a file system, or a time in a log entry, etc. A time system on a file system with a limited range is not a problem. That media is not going to be active 40 years later. The file may last longer but in such cases presumably it's copied to new media with a different method of storing times. So not a problem for file systems to do this. The problem however is that this time system was expanded to be used for more general purpose times. And over time it's practically a de-facto standard to stick with time_t and its 1/1/1970 base date. People don't think about converting from system time into an external time when exporting data, they just assume time_t is valid everywhere. Programmers just use whatever time system they find in the system's libraries without worrying about whether it is an appropriate use or not.
Many application areas already have to avoid using time_t anyway and are used to converting between one time system to another. Astronomy, geneology, medical records, historical data, etc.
Re: (Score:3)
Actually, banks, and such already ran into Y2K problems in the 70s when long term loans starting overflowing them. For them the Y2K scenario had many years to be fixed slowly (mostly a continuous updating thing - as things broke, they fixed it) so there was no big rush for them as they were experienced in such issues.
It's times like this when I really, really miss VMS.
lazy programmers, kicking the can down the road (Score:5, Funny)
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
Re: (Score:3)
I think that depends on your architecture. On my system, time_t is eventually defined as long. This makes it 32 bits if the compiler is compiling for ILP32 and 64 bit if it is compiling for LP64.
Not NetBSD (Score:5, Informative)
NetBSD has switched to a 64-bit time_t.
Re:Not NetBSD (Score:4, Insightful)
Re:64-bit computers DO NOT solve this problem (Score:4, Insightful)
Re:64-bit computers DO NOT solve this problem (Score:5, Insightful)
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.
Re:64-bit computers DO NOT solve this problem (Score:5, Insightful)
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.
Re:64-bit computers DO NOT solve this problem (Score:5, Funny)
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.
Re:64-bit computers DO NOT solve this problem (Score:5, Funny)
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.
Re:64-bit computers DO NOT solve this problem (Score:5, Interesting)
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.
Re:64-bit computers DO NOT solve this problem (Score:5, Insightful)
$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.
Re: (Score:3)
You can see why people are extremely reluctant to tinker with man-rated systems.
Re:64-bit computers DO NOT solve this problem (Score:5, Informative)
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.
Re:64-bit computers DO NOT solve this problem (Score:4, Informative)
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."
Re: (Score:3)
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.
Re:64-bit computers DO NOT solve this problem (Score:5, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:3)
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 [sodiumeyes.com].)
embedded (Score:5, Informative)
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).
Re: (Score:3)
Most systems really don't deal with the 64-bit times that much, especially embedded systems. Instead they have their own system time. Even Unix systems don't use Unix time_t internally in the kernel, they need a time domain with a finer granularity. So systems do all their OS work with an internal system time, and only when an application needs to convert to time_t is the 64-bit conversion done and used externally.
Sometimes the embedded systems wont' do Unix time at all and then it's up to the external a
Re:Not NetBSD (Score:5, Informative)
The problem is not so much the OS, as you say most systems will be running 64-bit operating systems and even 32-bit operating systems will likely find a soloution (like was done for large file support). The problem is the applications which have the assumption of 32-bit unix time built in.
You might say "just recompile for 64-bit" but that assumes that
1: you have the source
2: the source is not full of assumptions that make rebuilding for 64-bit impractical
3: the source actually stores the time in variables of type time_t or long and not variables of type int or type int32_t.
4: the data files the program stores on-disk do not include timestamps in unix format in fixed size fields.
For what proportion of applications do you belive all four of those assmptions will hold.
Re:Not NetBSD (Score:5, Informative)
> Are you trying to say that "64-bit computers" don't have any support for 32 bit integers?
The issue is if time_t is a 32-bit int or a 64-bit int. Not if a bit-64 CPU supports 32-bit integers.
time_t is generally defined as a long across OS implementations.
In the 32-bit ABI (Application Binary Interface) for most (all?) OSes, a long is a 32-bit value.
In the 64-bit ABI, a long is 64-bits, so the 2038 time issue does not exist for 64-bit apps.
So if you are running a 64-bit app, you don't have a problem in that app. One solution is to
not support 32-bit apps anymore. i.e. you don't support the 32-bit ABI in your 64-bit kernel.
You can do this easily in linux today (e.g. gentoo, 64-bit only support).
Another solution is to break 32-bit compatibility (or to define a new 32-bit "ABI") which
changes the definition of time_t (and some other system types) to be a [u]int64 instead
of a long.
So, *if* the parent was suggesting don't support 32-bit apps, then they were right ;-)
Re:Not NetBSD (Score:5, Funny)
In the 64-bit ABI, a long is 64-bits, so the 2038 time issue does not exist for 64-bit apps.
Perhaps not, but that Y292e9 bug is going to cause some serious headaches for the Pang-Galactic Empire.
Re:Not NetBSD (Score:5, Interesting)
The main problem is actually not that the time_t in the OS is 32 or 64, hardware and operating systems are upgraded. And, very few systems shipping today will have 32 bit time_t. This will not be the main problem (even if it will be a problem with some systems, for example, some nuclear reactors are managed by custom unices that are not maintained anymore and they don't dare to touch those systems, but this is solvable in the few cases where this is a problem)!
The BIG problem for more mainstream software is all the software using binary file formats, such software will completely break down, if time is stored as a 32 bit UNIX time stamp. There may also be problem for text based file formats if for example the reading code uses %d with sscanf to read in the timestamp, but if these are compiled with a modern compiler, the compiler will warn that %d is being used with a 64 bit time_t integer. It is thus solvable, but will require recompiling the software and some minor patching. Binary file-formats will however be a pain in the ass, so bad that software systems will probably have to be certified as Y2038-safe.
Do not underestimate the size of this undertaking.
Re:Not NetBSD (Score:4, Insightful)
If we even are alive by then.
Re: (Score:3)
If we even are alive by then.
Clever. So very, very clever,
But that is not the way a civil engineer thinks. It is not the way an accountant thinks.
If you are ready to retire to your Cold War era bunker in the backwoods of Idaho, fine. If you are looking for gainful employment in the production and maintenance of mission-critical systems, look elsewhere, because we don't need you, don't want you,
Re:Not NetBSD (Score:5, Interesting)
Except that it wont happen for 25 years... FEAR, UNCERTAINTY, CHANGE... RUN!!!!! THE SKY IS FALLING!! (in 25 years)...
With the acceleration of development that has been occurring over even the last 10 years, I hardly doubt there will be much to worry about 25 years from now.
You sound like a manager.
Leave this on the back burner for the next 24.5 years and then drop everything because then the sky is falling.
I'm glad this issue got mentioned because frankly I don't ever think about the unix epoch time overflowing. It's a good thing to give programmers a nudge for their current(and future) development
"Hey use 64 bit time values"
"Oh yeah, sure,"
25 years later, no problem.
Re: (Score:3)
In the 64-bit ABI, a long is 64-bits
Not true for Windows. On Windows you need a long long to get the native integer size on 64-bit processors. A pointer on Windows 64-bit does not fit in a long.
On the bright side, Windows does not use the "offset from 1970" method of storing time. Whether the Windows method is better is debatable, but it certainly has no Y2k38 problem.
Re: (Score:3)
I'm sorry, but I'm just not sure how this got modded insightful... This post, like many others, seems to completely ignore the fact that data is stored.
TODAY 32 bit UNIX systems are legacy. both in hardware and software. There are 64 bit drop in solutions for just about everything. The way TIME works in UNIX, a simple recompile against 64 bit libraries with a 64 bit system clock will fix the program.
It isn't simply a recompile. You still have to deal with your data, however it is stored. It might be a relatively simple migration, or it might involve data on tapes or other historical data archives, or interoperating with other devices/systems that aren't 64-bit and can't simply recompile (such as embedded systems), or it still might communicate with ot
Re: (Score:3)
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.
Re: (Score:3)
Yup, the KC-135's (introduced in 1957), I worked on in the 80's, and my father worked on in the 60's. They're still in active service today, with projected use through 2040. But yeah, avionics upgrades out the yin yang.
As for cars, as long as they allow '68-'72 Chevys on the road, i'll be happy.
Re: (Score:2)
At least 64 bit Linux has too. The only 32 bit installation I have (on a Raspberry Pi) has not.
Re: (Score:2)
Don't forget the Rpi doesn't even have a real time clock...
Re: (Score:2)
Yes, I know. A limitation found on quite a few other embedded systems. My intuition is that on something without real-time clock, this issue cannot be important.
Re: (Score:2, Informative)
AFAICT, Linux typedefs time_t to long, which will be 32 bits on 32 bit systems and 64 bits on 64 bit systems.
There shouldn't be too many 32 bit desktops around in 25 years, but I can easily imagine some long forgotten embedded systems starting to act funky.
Re:Not NetBSD (Score:5, Insightful)
The problem is not so much in computers still being 32 bits in 25 years time, but 32 bit computers right now doing calculations involving dates 25 years in the future.
Re: (Score:3)
At the time K&R wrote it, people didn't use "operating systems" as "platforms" for "applications" as much as they were just the first tape you loaded onto the core in
That's OK (Score:5, Funny)
I feel like the security guard in Austin Powers... (Score:5, Funny)
Standing before the steam roller....
"Stoooooooooooooooooooooooooooooooooooooooooooop".... .... "Stooooooooooooooooooooooooooooooooop"....
I understand, we need time to correct the issue, but...c'mon?!
Slow news day?
Unsigned! (Score:4, Interesting)
Re: (Score:3)
no you heard correct.
"What'd be the negative timestamps for? Ages before 1970?"
but you managed to guess this correctly.
Re: (Score:3)
Also a timestamp, in addition to being referenced to 0 = somesuch date, also can be used with offsets. So add a signed integer "-60" to the timestamp signed integer to get a signed integer representing about a minute ago. Since you'll be spending a lot of time adding signed ints to a timestamp, you may as well make the thing a signed int, rather than having to screw up and debug a zillion crappy bug filled homemade implementations of "uint + int = uint". Most of the bugs are dealing with extreme values a
Re: (Score:3)
Do the math. If they used a 32-bit unsigned integer, the problem wouldn't happen until the year 2106.
Re: (Score:3)
We made this decision for our C library on our embedded 65816 processor used in industrial controllers. We had no reason to represent times before the controller was installed, so losing the sign wasn't an issue. But we thought that 2038 was within the possible useful life span of the controller. 2106, not so much.
I realize that many people thought that about hardware produced for the century turnover as well, so everything about the time range is internally documented well, but we didn't have any justifica
Re: (Score:3)
Ages before 1970?
Some applications need to represent times before 1970 (for example dates of birth*)
Some applications need to work with time differences.
Some applications use negative numbers to represent errors.
Unsigned 32-bit unix time values may be useful as a quick fix in some specific scenarios where a field in a data structure is fixed size, where it is accepted that the code processing that field will need to be updated and where it is known that dates before 1970 will not be needed but attempts to use them as a gene
Getting old (Score:3)
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.
Re: (Score:3)
Yep. We knew Y2K was coming. We tested stuff. We fixed stuff. We got double-time for being on-call instead of partying like it's 1999. And because of all of that, it went smoothly.
The same thing will happen here. All it needs is for management to put people on the tasks.
Mortgage Calculations (Score:5, Insightful)
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.
Re:Mortgage Calculations (Score:5, Funny)
Actually we did, but it had nothing to do with integer overflow.
Re: (Score:2)
The global crysis!
I blame UNIX for that!
Re:Mortgage Calculations (Score:4, Funny)
Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages.
Oh, that was what that was. Oh crap.
And here all along I've been blaming greedy mortgage brokers for suckering people into mortgages they couldn't afford and a insanely inflated real estate market.
Re: (Score:2)
Five years ago there was an economy-shattering real estate crash due to shady sub-prime mortgages. Coincidence or coverup?
Just kidding; of course it was a coincidence. But if you throw out statements like this, the conspiracy theorists come out of the woodwork. You could even say the moon landings were faked because the time on the computers of the day was kept in an 8-bit register, which rolled over during the Apollo 13 mission!
Re: (Score:2)
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.
Maybe that's because accountant types seem to think that the only valid numerical inaccuracies are those manifested in base 10, so they tend to use their own weird decimal number types for financial calculations.
Oh No! (Score:2)
This could be worse than Y2K!
Re: (Score:2)
This could be worse than Y2K!
. . . and more lucrative, for retired C hackers who want to earn a few bucks . . .
The COBOL boys had their turn with Y2K. Next up, are the C-bies.
Noooooooo! (Score:5, Funny)
My uptime!
Surely we'll all be using 64bit by then. (Score:3, Funny)
After all, we handily averted Y2K with decades to spare, and the internet has been migrated to IPv6 for the past ten years. :-P
Re: (Score:2)
And the Mayan clock rollover didn't seem to cause any problems.
WP article much better (Score:2)
The Wikipedia article [wikipedia.org] is much better than the Byte article. (Do people still read Byte? I don't remember seeing it since the 80's.)
One thing that seems a little different from Y2K is that this bug seems to be prevalent in a lot of embedded systems. To me that seems harder to test than a desktop system. On a desktop system, you can just set the time to Dec. 31, 2037, let it roll over, and test as much stuff as possible to see if it broke. You can't do that with a car or an airliner.
Re: (Score:2)
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 auto
Re: (Score:3)
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.
Re: (Score:2)
They're probably talking about endless dependency stream style bugs.
For example. Say your shitty GPS rx curls up and dies with the 32 bit roll over. So it either stops sending fixes to the moving map or the moving map decides not to accept post-32-bit timestamps as part of the NMEA stream. Either way the position becomes static so the calculate airspeed drops to zero. Normally it would cross check against the two tubes, but those are clogged by ice today. So the autopilot shoves the stick far over beca
Re: (Score:2)
(Do people still read Byte? I don't remember seeing it since the 80's.)
Only in strings. We migrated to Words in the late '80s, then DWords in the '90s.
Re: (Score:2)
will most embedded systems need the date to work as an absolute, ot just need to count seconds? Why does an industrial robot care if its 2038 or 1901?
Since When Do Politicians Use Unix? (Score:2)
>> those phony programs politicians use to project government expenditures
That's Excel in most cases, I bet. As long as spreadsheets can handle up to 50 rows and numbers up to 3000 I suspect all will be as it is today.
Time overflowing (Score:4, Funny)
I'll be 70 or dead (Score:2)
So it will be someone else's problem.
Well (Score:2)
"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 a
Re: (Score:2)
I expect that financial calculations are using 64 bit or 128 bit integers, long-numbers or at the very least (may be illegal in some countries) double. The last still gives 56 bit integer precision when misused as an integer.
Another Global Warming Scare (Score:2)
Cowboy Robot is yet another example of someone trying to use "facts" to create alarm, raise money, and achieve world government. If there were really a time problem in UNIX, and I don't believe it for a moment, it's not necessarily caused by human activity. I prefer sunspots. Yeah. Sunspots.
Simple fix (Score:2)
I already warned people weeks ago (Score:2)
http://slashdot.org/comments.pl?sid=3356429&cid=42468505 [slashdot.org]
But thanks for pointing it out again. Don't forget to stock up on Spam and Treet.
typedef int64_t time_t; (Score:2)
Shhhhh!! (Score:4, Interesting)
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.
VMS never had this problem (Score:2)
A real problem! (Score:2)
In 25 years? (Score:3)
Not a problem since we'll all be running Windows 11 by then.
Re: (Score:3)
Comment removed (Score:3)
Re:Is it a real problem? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
and your loans will be like 500K
Per textbook