Rolling Over

Today is the last day of February. There are just ten more months until 2020. We have just eighteen years to replace all of our 32-bit *nix-based systems that need to understand what day it is1. As one would expect from a person who embarks upon a 1,000-year project, time is something that I think about quite often. A lot of people knew about Y2K before it happened. Some people know about Y2038. Very few people (that I know) seem to be aware of the two other impending date-based issues that will affect our technology in the near future. One is the Network Time Protocol rollover on February 7th, 2036. The other is the GPS Week rollover on April 6th, 2019; a little less than six weeks from now.

Fortunately most of our modern technological devices will be ready for the GPS rollover as regular software updates to cell phones, tablets, and desktop operating systems make this a relatively painless bit of math. One area that I expect to see suffer from hiccups, however, will be car-mounted navigation systems. These expensive tools are not known for quality code or regular software updates, which means that some people can expect to see the displayed date in their car to be off by almost 20 years.

The problem basically breaks down like this. The GPS satellites use a 10-bit number to keep track of what week it is. 10-bits has a maximum human-readable value of 1,024. This number of weeks works out to 19.7 years, and every one of these periods is known as an epoch. We're currently at the tail end of the second epoch. From April 6th the week number will roll over to 0 and we'll enter the third. If you have an in-dash navigation system in your car, now would be a good time to see if it's possible to update the software.

Then in 2036 …

Another epoch will be coming to an end in 2036 when the Network Time Protocol runs out of numbers and resets. What's interesting is that NTP uses a 64-bit time value, which should theoretically be large enough to count the number of seconds between the birth and death of our universe. NTP, however, consists of two 32-bit parts; one for seconds and another for fractional seconds. This means that NTP will roll over every 232 seconds, which is about 136 years. Unlike Unix, NTP's first epoch has a start date of January 1, 1900, meaning that it will run out of seconds on February 7th, 2036 at around 06:28:15 UTC. Given that it's network-connected devices that make use of NTP to synchronize their time when booting, and most modern systems will not allow their internal clock to be set to a date before 1970, it shouldn't be too difficult a task for systems to understand when the second epoch begins and just roll with it.

We should still make sure that everything is tested and in place beforehand, though.

Y2038

A Visual Representation of the Y2038 Problem

And then there's the next big epoch to overcome: the Unix timestamp. These numbers are used, quite literally, everywhere. Me being me, I've yet to go a day in the last decade or so where I didn't knowingly use, see, or read a Unix timestamp. What's interesting is that there is no universal solution to this problem. A lot of modern systems support the newer 64-bit timestamps, but there are a lot of lower-powered or older devices that use 32-bit processors where a 64-bit timestamp simply will not work, and any change to how the 32-bit number is parsed would open a huge can of worms that would result in a decade of bug-hunting. Most modern Unix-based systems built in the last five years will be good until the 64-bit epoch hits us on December 4th, 292,277,026,596. This isn't something most of us will need to worry about.

Our 32-bit systems, though … these will come back to haunt us. Thermostats, refrigerators, and other home appliances can last a long, long time. Not all of these devices will need to know the exact date to function, but some will have schedules to follow. If the calendar rolls back to the early 20th century, who knows what sorts of activities an appliance might not automatically handle for us.

The Unix epoch will likely be mostly resolved in the next couple of years as smart people sit down and tackle the problem. Some older hardware and software will not be salvageable, but this won't stop solutions from being brought forward and implemented. The one area where I am concerned about this roll over is in the older, legacy systems that some companies still run. Many organizations that use software originally written in the 80s and 90s for 32-bit mainframes most likely run these systems in virtual machines now rather than on 20+ year old hardware. The great thing about running software in a virtual machine is that these complex systems are incredibly portable. Server hardware can continue to evolve and get replaced every few years, and the virtual machine can be booted up on a new machine in a matter of minutes to take over from a decommissioned system. It's both cost effective and smart. As time goes on, though, the people who know how to maintain the software on those virtual machines retire. As people retire, they take important skills with them. When nobody with the requisite skills remains to manage the legacy system, it becomes a "black box" that nobody touches until someone in 2037 asks if the company is ready for the Unix epoch.

Then we have another Y2K moment.


  1. The Y2038 problem will not be talked about nearly as much as Y2K was, nor will most people even realize its significance.