25 Years From Today: A Time for Bugs

25 years from today, January 19, 2038, at 03:14:08 UTC, 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, as demonstrated in this animated GIF:

For more detail on the problem, see the Wikipedia article on it. Wikipedia also has an article with an interesting collection of important time formatting and storage bugs, including Year 2038, Y2K, Days 32,768 and 65,536 and Year 10,000.

This was the same generation of people who decided that 32 bits was certainly enough for all the IP addresses in the world and, if it weren't, we'd just make a new standard. The lack of forethought in both decisions has led to analogous problems: Designing a new standard is easy, but adapting all the existing software which relies on the old standard is very, very hard. The time_t problem is somewhat sloppier though, because if they had only made it an unsigned integer the life of the data type would have extended to the year 2106.

There have long been new time data structures with longer life spans and they are in wide use, but not exclusive use. For instance, in iOS programs must use the NSDate class for dates. NSDate uses January 1, 2001 as a reference date and intervals before or since that point are stored as doubles, which are IEEE 64-bit (8-byte) double-precision floating-point numbers. Apple says this method "...yields sub-millisecond precision over a range of 10,000 years."

Hat tip for reminding me of this pre-anniversary to the great Mikko Hypponen on Twitter. Mikko also noticed, as demonstrated just below, that some systems exhibit Year 2038 problems already. The iPhone below is running the current iOS 6.0.1, and when you set it to any date beyond January 19, 2038 it resets to January 1 of that year and the date, and the subsequent years are grayed out.

It's odd and it doesn't necessarily mean anything. Mikko adds that Android exhibits the same behavior but that Windows Phone works correctly. It's also ironic, since Apple has enforced the use of the NSDate structure.

[Update: I have confirmed Mikko's Android report on a Google Nexus 7 tablet running Android 4.1 Jelly Bean — Even though years beyond 2038 are listed in the Set Date and Time function of the Settings app, Try to set it to a date past 1/19/2038 and it refuses.]

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. No doubt people responsible for such software have been aware of this for years and have been addressing it.

Don't start panicking, but don't completely blow the problem off. As with Y2K, nobody really knows the extent of the problem and we won't for a while. With any luck, it will be as big a disaster as Y2K.