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.

IoT
IoT
Infrastructure // PC & Servers
Commentary
1/19/2013
05:41 PM
Larry Seltzer
Larry Seltzer
Commentary
Connect Directly
Twitter
Facebook
Google+
LinkedIn
RSS
E-Mail
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
georgej
50%
50%
georgej,
User Rank: Apprentice
11/28/2013 | 1:48:34 PM
....
The Epochalypse!
Slideshows
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
Commentary
The Growing Security Priority for DevOps and Cloud Migration
Joao-Pierre S. Ruth, Senior Writer,  9/3/2020
Commentary
Dark Side of AI: How to Make Artificial Intelligence Trustworthy
Guest Commentary, Guest Commentary,  9/15/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Slideshows
Flash Poll