The year 2038 has bugs

0
I WAS WORKING AS A SYSTEMS ADMINISTRATOR IN A COMMERCIAL ISP WHEN RUMORS OF THE Y2K BUG STARTED TO SPREAD. ALTHOUGH WE WERE QUITE SURE THAT NOTHING DISASTROUS WOULD HAPPEN ON NEW YEAR’S EVE OF 1999, WE STILL CAMPED OVERNIGHT IN THE OFFICE, PARTLY ANXIOUS AND PARTLY CURIOUS TO SEE HOW THE EVENT WOULD UNFOLD.

The Y2K bug, a.k.a. the Millennium Bug, was an anticipated software malfunction that was caused by a programming flaw in an earlier software. It was a common practice then for programmers to shorten the full year i.e. “1999” into “99” to use less database storage. It was theorized that when the software incremented from “99” to “00”, dates could be misinterpreted as “1900” instead of “2000”, triggering a glitch in time-dependent software.

“Unfortunately, a limit in the capacity of UNIX-like systems to calculate time can trigger another digital doomsday that may happen sometime in the year 2038.”

Fortunately, nothing serious happened except for isolated cases; most of our critical systems here were still paperbased and were not directly affected. Also, most administrators had migrated ahead to UNIX systems, which were immune to the Y2K malady.

Unfortunately, a limit in the capacity of UNIX-like systems to calculate time can trigger another digital doomsday that may happen sometime in the year 2038.

Decoding the 2038 bug, Gangnam style

UNIX-like systems (i.e. Linux and Mac OS X) define time according to the POSIX epoch, the beginning of UNIX time. Each instance in the timeline is expressed as the number of seconds that elapsed since 1 January 1970 00:00:00 UTC (Coordinated Universal Time). To illustrate, this year’s  Valentine’s Day—Saturday, 14 February 2015, 12AM Philippine Standard Time—would have the value of 1,423,872,000,000 seconds.

Using absolute units (seconds) is very convenient for C programmers to find the difference between two UNIX time values. A standard C library for handling time takes care of this. The time value (data type time_t) is originally stored as a 32-bit integer. This means that the range of possible values it can hold is 2^32 or 4,294,967,296 (remember your binary lessons, kids). However, since UNIX time can accept both positive and negative numbers, you divide the range by two and get 2,147,483,647 in both directions plus a zero in the middle. Read more about bits and bytes here[1].

“One second after this will trigger an overflow error in a 32-bit application.”

Converting this value (in seconds) will give you approximately 68.0511 years. Add this to the UNIX epoch and you arrive at the maximum time of 3:14:07 AM on 19 January 2038. One second after this will trigger an overflow error in a 32-bit application.

The realistic effects were uncannily demonstrated by the YouTube video of Psy’s Gangnam style. The official YouTube blog wrote, “We never thought a video would be watched in numbers greater than a 32-bit integer (=2,147,483,647 views), but that was before we met Psy. “Gangnam Style” has been viewed so many times we buy viagra online had to upgrade to a 64-bit integer (9,223,372,036,854,775,808)!”

Thanks to the internet and Psy, the 2038 bug has recently gained much media attention.

What could happen?

We still have 23 years to fix this, but most operating systems have begun the shift to 64-bit systems. Software developers everywhere are already feeling the crunch to update their applications to new platform specifications to reduce possible software malfunctions.

This is where it gets tricky: most industrial and personal electronic devices were designed during the 32-bit era with 32-bit firmware directly embedded to the hardware. An upgrade in this scenario—with devices designed to last a long time, some beyond 2038—is near impossible and expensive.

What could happen if actions are not taken? Below are some possible scenarios:

– Inaccurate or zero information from weather instruments because the forecast track of typhoons would fail to receive accurate GPS (exact location in time and space) readings.

– Zero (yay) or horrendous (nay) mobile phone bills because UNIX time would mistakenly log calls.

– Loans beyond 2038 would not be calculated by microfinancing programs using the documented 32-bit MySQL UNIX_TIMESTAMP() function.

– Another massive #chickensad event on twitterverse because an inventory software of a particular local fastfood chain would fail to predict the correct quantity of chicken demand.

– Aircraft and cargo ships that have legacy-mounted navigational tools would be grounded, putting a strain on the global shipping industry, affecting global trade in the process.

“While shifting to 64-bit operating systems will let our computers work beyond 2038, this does not ensure our computers’ infallibility for all of eternity…”

I first encountered this bug in 2002 while doing design work on a smart scheduling module. Instead of creating a workaround, I decided to rule out the threat because I thought nobody would be using the same software in the year 2038. A decade later, that software was eventually replaced by a graphical interface running on a browser using a popup calendar script that could accept date inputs beyond 2038.

There is no universal solution to the Y2038 problem. In the Y2K problem alone, the Federal government of the United States spent almost $100 billion in software upgrades. In the Philippines, a Republic Act was passed requiring business entities to disclose year 2000 readiness, and an executive order established the Presidential Commission on Year 2000 Compliance[2]. Could there be a forthcoming commission for the 2038 bug?

While shifting to 64-bit operating systems will let our computers work beyond 2038, this does not ensure our computers’ infallibility for all of eternity: it has a wraparound date that is scheduled to expire—threatening malfunction of future computers everywhere—one Sunday afternoon on 4 December 292277026596.

Words VAL J. GONZALES
First published in Speed February 2015
[1]computer.howstuffworks.com/bytes.htm [2]chanrobles.com/articles7.htm