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 Kernel: 412k+ Lines of Code From AMD and Toolchains Microconference Accepted into 2019 Linux Plumbers Conference Roy Schestowitz 18/06/2019 - 4:42am
Story The Ecuadorean Authorities Have No Reason to Detain Free Software Developer Ola Bini Roy Schestowitz 11 18/06/2019 - 4:31am
Story Server: Red Hat, CentOS 8, Linux On ARM Servers and IBM Roy Schestowitz 18/06/2019 - 4:13am
Story today's howtos Roy Schestowitz 18/06/2019 - 4:10am
Story Audiocasts/Shows: Linux Gaming News Punch, GNU World Order and More Roy Schestowitz 1 18/06/2019 - 3:59am
Story Latest Security FUD in the Media Roy Schestowitz 18/06/2019 - 3:51am
Story Programming/Development: Zato, Wing, Receiving Code Review, CoffeeScript and BASIC Roy Schestowitz 18/06/2019 - 3:24am
Story Release of DragonFly BSD 5.6 Roy Schestowitz 18/06/2019 - 3:00am
Story Qt 5.12.4 Roy Schestowitz 18/06/2019 - 2:53am
Story PCLinuxOS KDE Full Edition 2019.06 Release Roy Schestowitz 2 18/06/2019 - 2:39am