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

Latest Security FUD in the Media

Programming/Development: Zato, Wing, Receiving Code Review, CoffeeScript and BASIC

  • Zato 3.1 Released - Open-Source Python-based API Integrations and Backend Application Server
    The newest version of Zato, the open-source Python-based enterprise API integrations platform and backend application server, is out with a lot of interesting features, changes and additions.
  • Extending Wing with Python (Part Two)
    To debug extension scripts written for Wing, you will need to set up a new project that is configured so that Wing can debug itself. The manual steps for doing this are documented in Debugging Extension Scripts. However, let's use an extension script to do this automatically.
  • Robbie Harwood: Receiving Code Review
    From a maintainer's perspective, that's the primary role of code review: to ensure project quality and continued maintainability. But there's an important secondary purpose as well: to help contributors (and potential contributors) learn and grow. In other words, receiving code review is a learning and growth opportunity, and should be approached as such. And so, first and foremost: code review is not a judgement on you. It's a second set of eyes, and both of you are trying to make sure the changes are good. If they didn't want the change in the project, they'd say so! Subtlety isn't what's happening here. And besides, if anyone were perfect, we would do code review. Which leads into: everyone needs code review. No change is too small for it, and no one is perfect. I've broken builds by changing only documentation, and flagged potential security issues from developers who have been coding almost as long as I've been alive. (And they've done the same to me!) That's normal. That's life. That's code review. And it's fine, because we don't need it to be perfect on the first try. Contributing to open source isn't a school exam where we get a single attempt and it's most of the grade. We're concerned only with improving our software, and if there's grading at all, it's externally imposed (e.g., by an employer).
  • Best Free Books to Learn about CoffeeScript
    CoffeeScript is a very succinct programming language that transcompiles into JavaScript, so there is no interpretation at runtime. The syntax is inspired by Ruby, Python and Haskell, and implements many features from these three languages. CoffeeScript is closely related to JavaScript without having its eccentricities. However, CoffeeScript offers more than fixing many of the oddities of JavaScript, as it has some useful features including array comprehensions, prototype aliases and classes. It allows developers to write less code to get more done.
  • 10 PRINT Memorial in New Hampshire marks the birthplace of BASIC
    After just over 55 years, the birthplace of BASIC has been honoured with a memorial marker in New Hampshire, USA. Thanks to a campaign by local paper columnist David Brooks, the New Hampshire Historical Highway Marker was installed earlier this month. Professor John Kemeny, Maths professor Thomas Kurtz, and a group undergraduate students at Dartmouth College (pics) created BASIC (Beginner's All-purpose Symbolic Instruction Code). The first program ran on 1 May 1964.

Audiocasts/Shows: Linux Gaming News Punch, GNU World Order and More

Release of DragonFly BSD 5.6

  • DragonFly BSD 5.6
    DragonFly version 5.6 brings an improved virtual memory system, updates to radeon and ttm, and performance improvements for HAMMER2. The details of all commits between the 5.4 and 5.6 branches are available in the associated commit messages for 5.6.0rc1 and 5.6.0.
  • DragonFlyBSD 5.6 Released With VM System, HAMMER2 In Good Shape
    DragonFlyBSD 5.6 is now available as the latest major update to this popular BSD operating system. DragonFlyBSD 5.6 brings the HAMMER2 file-system by default following numerous improvements this cycle to HAMMER2 to put it now in comparable/better standing than HAMMER1. HAMMER1 though remains available for those interested. I'll have out some new HAMMER2 DragonFlyBSD benchmarks shortly.