Language Selection

English French German Italian Portuguese Spanish

Preparing for Y2038 (Already?!)

Filed under
Linux

It somehow doesn't seem that long ago, but nineteen years ago during Y2K I spent my New Year's Eve in the Akamai Network Operations center, waiting to respond to anything that might go awry as the clock struck midnight in key time zones such as Greenwich and Boston. As of January 9, 2019, we are roughly half-way from Y2K to "Y2038", the next large time epoch roll-over event. In 2038 on January 19th the "Unix Epoch Time" will exceed the size of a signed 32-bit integer "time_t" value (231-1), or roughly 2.1 billion seconds since the epoch of 00:00:00 on January 1, 1970. We have somewhat more time to deal with the systems that will break nineteen years from now. However, as we get closer there will be increasing impacts on software working with future dates.

Shortly after Y2K we made jokes about "next up, Y2038!" but back then it felt an eternity in the future and likely to be someone else's problem. Now that we're halfway there, and we have already reached the point where Y2038 issues can cause software failures, it is a good opportunity to start planning for Y2038. For example, software may already be having issues working with 20-year certificate lifetimes or 20-year mortgages, and the frequency of these issues will only increase as we get closer to Y2038. At Akamai we are already running strategically-targeted internal planning and testing for Y2038, and it seems likely that the scope of this work will continue to grow over the next 19 years as this important effort increases in urgency.

Very little went wrong on January 1, 2000 for us (short of some Javascript on an Akamai marketing site displaying "1900" as the current date!), but one thing that gets missed is that the limited global impact that evening was due to two factors: 1) the amount of advanced preparation that was done; 2) many "Y2K problems" actually occurred years in advance rather than during the roll-over itself. Leap seconds are in some ways scarier than date-format issues in that they are harder to test for and much less of the impact happens in advance. There is a risk that the lack of impacts of Y2K may cause organizations and technologists to under-prepare for Y2038. It is also harder to explain "Y2038" to lay people than Y2K, potentially making it harder to prioritize and focus advanced work. The large number of embedded Internet of Things (IoT) devices becoming ubiquitous in our environment also makes the likely risk and potential impact considerably higher for Y2038 than it was for Y2K.

Read more

More in Tux Machines

Type Title Author Replies Last Postsort icon
Story Games: Overland, Lutris, Dead Cells and Fossilize Roy Schestowitz 25/03/2019 - 10:55am
Story Graphics: Wayland and Vulkan Roy Schestowitz 25/03/2019 - 10:52am
Story OSS: Blockchain, DeepBrain, Redox OS, OpenBuilds, Red Hat Summit and FOSSASIA Roy Schestowitz 25/03/2019 - 10:30am
Story SUSE: Future and Independence Roy Schestowitz 9 25/03/2019 - 10:27am
Story Reducing sysadmin toil with Kubernetes controllers Roy Schestowitz 25/03/2019 - 9:34am
Story Android Leftovers Rianne Schestowitz 25/03/2019 - 9:34am
Story Server: IBM, LAMP and Kubernetes Roy Schestowitz 25/03/2019 - 8:43am
Story today's howtos Roy Schestowitz 25/03/2019 - 8:30am
Story Software: Relational Databases, Low Footprint Web Browsers and Top 5 Linux Apps For Writing Roy Schestowitz 25/03/2019 - 8:22am
Story End of LibrePlanet 2019 Roy Schestowitz 25/03/2019 - 6:31am