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."
Not NetBSD (Score:5, Informative)
NetBSD has switched to a 64-bit time_t.
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: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.
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: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: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:Not NetBSD (Score:1, Informative)
Err, airplanes routinely fly much much longer than 10 years.
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: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.