Language Selection

English French German Italian Portuguese Spanish

Y2038 bug may hit Unix, Linux machines

Filed under
Linux

After the Millennium bug for which several billions of dollars were committed for research and updations in computer systems the world over, there is yet another bug on the horizon. It is the Year 2038 bug that is slated to hit computer users in that year.

To be precise, on Tuesday, January 19 03:14:07 2038, machines prone to this bug will alter calendars to go back to Friday, December 13 20:45:52 1901.

Computer programmers predict that this can result in incorrect and wildly inaccurate dates being reported by the operating system and applications. It is likely to cause serious problems on many platforms, especially Unix and Unix-like and Linux platforms, because these systems will "run out of time". They are reluctant to predict the extent of the damage.

What is special about this date? It is explained that Unix and similar operating systems do not calculate time based on the Gregorian calendar. Instead, they are known to simply count time in seconds from their arbitrary "birthday", that is, GMT 00:00:00, Thursday, January 1, 1970. The accepted practice among software programmers is to use a 32-bit variable for this number (32-bit signed time_t). The largest possible value for the end integer in this calculation is 2**31-1 = 2,147,483,647. So, 2,147,483,647 seconds after Unix's birthday falls on Tuesday, January 19, 2038. And one second later, theoretically Unix systems will revert to their birth date (like an odometer switching back from 999999 to 000000).

Experts are of the opinion that Linux users will be the hardest hit, because of the wider acceptance of this OS for its security and cost features. They are feared to grind to a virtual halt or go into a loop. This Linux's own Y2K nightmare can be more damaging than the Y2K bug, because the latter basically involved applications while the 2038 bug affects the time-keeping function itself.

Linux gurus are apprehensive about the bug's impact on the embedded field, where software does not get replaced frequently. As such, major telecom gadgets and equipment will be greatly affected. However, one ray of hope is that the 32-bit processing can be replaced thus overcoming the impact of the bug -- definitely before 2038.

But, the optimism must end there. The bug can have severe impact on records created today with calculations going beyond 2038, like insurance policies. There could be error messages splashing on Unix and Linux screens then. And Linux is getting to be the popular operating system these days.

Experts say one and sure-short way to overcome the problem is to switch over to 64-bit or longer time_t data storage. Some of the existing 32-bit codes can be changed and the programs recompiled. However, all these are not very easy tasks.

Source.

Gone

I'll be dead by then so I'm not worried.

me too

that's what I was thinking... or at least so old I won't care... Tongue

----
You talk the talk, but do you waddle the waddle?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Leftovers: Software

  • OpenVZ 7.0 Becomes A Complete Linux Distribution, Based On VzLinux
    OpenVZ, a long-standing Linux virtualization technology and similar to LXC and Solaris Containers, is out with their major 7.0 release. OpenVZ 7.0 has focused on merging the OpenVZ and Virtuozzo code-bases along with replacing their own hypervisor with that of Linux's KVM. Under OpenVZ 7.0, it has become a complete Linux distribution based upon VzLinux.
  • OpenVZ 7.0 released
    I’m pleased to announce the release of OpenVZ 7.0. The new release focuses on merging OpenVZ and Virtuozzo source codebase, replacing our own hypervisor with KVM.
  • Announcing git-cinnabar 0.4.0 beta 2
    Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.
  • FreeIPA Lightweight CA internals
    In the preceding post, I explained the use cases for the FreeIPA lightweight sub-CAs feature, how to manage CAs and use them to issue certificates, and current limitations. In this post I detail some of the internals of how the feature works, including how signing keys are distributed to replicas, and how sub-CA certificate renewal works. I conclude with a brief retrospective on delivering the feature.
  • Lightweight Sub-CAs in FreeIPA 4.4
    Last year FreeIPA 4.2 brought us some great new certificate management features, including custom certificate profiles and user certificates. The upcoming FreeIPA 4.4 release builds upon this groundwork and introduces lightweight sub-CAs, a feature that lets admins to mint new CAs under the main FreeIPA CA and allows certificates for different purposes to be issued in different certificate domains. In this post I will review the use cases and demonstrate the process of creating, managing and issuing certificates from sub-CAs. (A follow-up post will detail some of the mechanisms that operate behind the scenes to make the feature work.)
  • RcppArmadillo 0.7.200.2.0
    The second Armadillo release of the 7.* series came out a few weeks ago: version 7.200.2. And RcppArmadillo version 0.7.200.2.0 is now on CRAN and uploaded to Debian. This followed the usual thorough reverse-dependecy checking of by now over 240 packages using it. For once, I let it simmer a little preparing only a package update via the GitHub repo without preparing a CRAN upload to lower the update frequency a little. Seeing that Conrad has started to release 7.300.0 tarballs, the time for a (final) 7.200.2 upload was now right. Just like the previous, it now requires a recent enough compiler. As g++ is so common, we explicitly test for version 4.6 or newer. So if you happen to be on an older RHEL or CentOS release, you may need to get yourself a more modern compiler. R on Windows is now at 4.9.3 which is decent (yet stable) choice; the 4.8 series of g++ will also do. For reference, the current LTS of Ubuntu is at 5.4.0, and we have g++ 6.1 available in Debian testing.

Red Hat and Fedora

Leftovers: Debian

  • Debian LGBTIQA+
    I have a long overdue blog entry about what happened in recent times. People that follow my tweets did catch some things. Most noteworthy there was the Trans*Inter*Congress in Munich at the start of May. It was an absolute blast. I met so many nice and great people, talked and experienced so many great things there that I'm still having a great motivational push from it every time I think back. It was also the time when I realized that I in fact do have body dysphoria even though I thought I'm fine with my body in general: Being tall is a huge issue for me. Realizing that I have a huge issue (yes, pun intended) with my length was quite relieving, even though it doesn't make it go away. It's something that makes passing and transitioning for me harder. I'm well aware that there are tall women, and that there are dedicated shops for lengthy women, but that's not the only thing that I have trouble with. What bothers me most is what people read into tall people: that they are always someone they can lean on for comfort, that tall people are always considered to be self confident and standing up for themselves (another pun, I know ... my bad).
  • [GSOC] Week 8&9 Report
    This particular week has been tiresome as I did catch a cold ;). I did come back from Cape Town where debconf taking place. My arrival at Montreal was in the middle of the week, so this week is not plenty of news…
  • Debian on Jetson TK1
    I became interested in running Debian on NVIDIA's Tegra platform recently. NVIDIA is doing a great job getting support for Tegra upstream (u-boot, kernel, X.org and other projects). As part of ensuring good Debian support for Tegra, I wanted to install Debian on a Jetson TK1, a development board from NVIDIA based on the Tegra K1 chip (Tegra 124), a 32-bit ARM chip.
  • RC bugs 2016/01-29

Android Leftovers