25 Years From Today: A Time for Bugs - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Infrastructure // PC & Servers
05:41 PM
Larry Seltzer
Larry Seltzer
Connect Directly

25 Years From Today: A Time for Bugs

25 years from today, January 19, 2038, at 03:14:08 UTC, a lot of software will fail if it's not fixed, and some has already begun to fail. It's not worthy of Y2K-level panic, at least not yet, but there are still many examples of programs that won't work, and the ensuing problems are beginning to crop up on us. As with Y2K, nobody really knows the extent of the problem and we will learn as time goes by, but with any luck, it will be as big a disaster.

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
How CIO Roles Will Change: The Future of Work
Jessica Davis, Senior Editor, Enterprise Apps,  7/1/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Flash Poll