2038: Y2K 2.0?

Who could forget Y2K? I have fond memories of counting down to midnight on January 1, 2000 prepared to witness planes fall from the sky and neighbors rushing to their cars to initiate bank runs as computer systems reverted back to William McKinley's presidency. Little chaos actually occurred, of course, even in non-remediated computer systems. In the present day, though, worrywarts have set their sights on 2038, the latest date bug for which we're all currently unprepared.

Since the dawn of widespread computer systems date bugs have occurred for various reasons. Systems crashed on January 4, 1975 because that date overflowed the 12-bit time field in certain operating systems. The less-publicized Y2K+10 problem was due to a variance in the way hexadecimal and binary-coded decimal (BCD) represent numbers. In short, BCD systems mistakenly read hexadecimal encoding as "2016" rather than 2010, deactivating 20 million German bank cards but not much else. And the original Y2K was an issue because early time systems represented years as two digits rather than four, so unmodified computers would represent 2000 as 1900.

Y2038 is pretty similar to the 1975 incident in that it's essentially an overflow problem for Unix or Unix-like systems. These systems encode dates as a 32-bit integer, time_t, representing the number of seconds since the Unix epoch, 00:00:00 Coordinated Universal Time (UTC) on January 1, 1970. In the constantly incrementing binary integer, the first digit has always been 0, representing a future date post-1970. But the integer will wrap at 3:14:07 UTC on January 19, 2038. At this point, it will be a 1 (indicating a "past", or pre-1970, date) followed by a string of 31 zeroes, leading systems to encode a date of December 13, 1901.

Early programmers used 32-bit Unix coding because they didn't have the luxury of using fast, cheap memory and processors like the ones we run into today. A number of modern data structures still use 32-bit embedded time representations, however. File systems, databases, older COBOL systems, manufacturing equipment, and certain medical devices are all at risk of failure if not corrected.

Because this problem has been recognized and defined a good 23 years before its critical failure point, some researchers believe that some future technology might be able to bypass the situation altogether without any scrambling to modify today's systems. It's also reasonable to assume that at least some existing systems will be updated, and that fixes could become sticky. Remapping time_t to a 64-bit integer is simple enough, but persistent data migration could be time-consuming and costly. And if file system data is incorporated into remote networks, techs must update time values across all points of the system at once.

We don't know exactly what'll happen in January 2038. Long-lived embedded systems with future planning and forecasting cycles might cause minor infrastructure difficulties if not upgraded. Twenty years from now might therefore be a great time to get into IT consulting, yet as the old IT adage goes: if the job gets done and done well, no one will notice anyway.

Image credit: John Swindells / CC BY-SA 2.0