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."

Comments

Not NetBSD

[Nimey]

NetBSD has switched to a 64-bit time_t.

Re:Not NetBSD

[mrjatsun]

> 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 ;-)

embedded

[Anonymous Coward]

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:Could we be a little less biased?

[tlhIngan]

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.