24

I am a bit concerned about this. It's called the "year 2038 problem". Is the Linux kernel or Ubuntu ready to handle dates after this yet, as of 12.04?

  • 8
    Have you tried setting your clock to something like January 19, 2038 3:14:07 and wait a second? – gertvdijk May 24 '13 at 12:11
  • 2
    Let's assume this problem exists and is not fixed yet. 12.04 will not be supported forever, so you and all other people will be on an updated distribution until this happens, since there are many years between. Updating is easy. One of these updates will surely contain a fix. So there is no reason to be concerned, but this is indeed an interesting question. – verpfeilt May 24 '13 at 12:21
  • 3
    The bug was already fixed. – ThePiercingPrince May 24 '13 at 12:27
  • The system clock won't (not on a reasonably recent kernel anyway); some data structures (and the programs using it) might exhibit anomalous behavior. In my opinion, this will be a problem with embedded devices - those are much less likely to be running current code. – Piskvor left the building May 24 '13 at 12:57
  • 1
    @hmayag: I wasn't thinking "toaster," more like "traffic light controller." Those things are a bit more rugged than consumer-grade electronics, and could easily exceed that lifespan (with part replacements, but possibly without upgrades) - IIRC, there were some issues with such 1980s electronics just after Y2K. – Piskvor left the building May 24 '13 at 14:30
14

No, it will not fail. In the worst case, from the viewpoint of a programmer it will work as expected: it will be reseted to date 1901-12-13 20:45:52:

enter image description here

This in case you will not update your current distributions until this happens. "Updating is easy. One of these updates will surely contain a fix." like chocobai said.

I remember that it was the same problem/question with 16-bit machines before 2000 and in the end it wasn't any problems.

A solution from Wikipedia:

Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 on Sunday, 4 December 292,277,026,596. The ability to make computations on dates is limited by the fact that tm_year uses a signed 32 bit int value starting at 1900 for the year. This limits the year to a maximum of 2,147,485,547 (2,147,483,647 + 1900). While this solves the problem for executing programs, it does not solve the problem of storing date values within binary data files, many of which employ rigid storage formats. It also doesn't solve the problem for 32-bit programs running under compatibility layers and may not solve the problem for programs that incorrectly store time values in variables of types other than time_t.

I use Ubuntu 13.04 on 64-bit and, by curiosity, I changed manually the time to 2038-01-19 03:13:00. After 03:14:08 nothing had happened:

Date and time before 2038-01-19 03:14:08 Date and time after 2038-01-19 03:14:08

So there is nothing to be concerned about this problem.

More about:

| improve this answer | |
  • 9
    If it resets, it fails because by "fail" I mean "not work or work incorrectly". – ThePiercingPrince May 24 '13 at 14:41
  • 1
    @LinuxDistance This happens from your point of view. But from the viewpoint of a programmer it will work as expected: it will reset. It was the same with the end of mayan calendar: the world didn't fail because of this. – Radu Rădeanu May 24 '13 at 15:02
  • 10
    I disagree? from the viewpoint of a programmer a clock isn't supposed to reset, so it will fail – Nanne May 24 '13 at 15:08
  • 3
    This discussion in the comments is pointless imo. The question is "Is the Linux kernel or Ubuntu ready to handle dates after this?". Well, it's not capable of handling such dates, so it fail in the context of this question. – gertvdijk May 28 '13 at 8:10
  • 2
    @gertvdijk "Is the" current/actual "Linux kernel or Ubuntu ready to handle dates after this?" – Radu Rădeanu May 28 '13 at 8:17
7

You can check if your computer's time will crash by using the following Perl script:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

If your computer will be fine, you will get this:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

If your computer is like mine, it'll wrap around like this:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

It could also do this:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
| improve this answer | |
  • I think you're testing Perl here and not the real operating system in the core. Or are you, with the use of ctime? – gertvdijk Jun 25 '13 at 23:14
  • @gertvdijk Well, it gives the first output on patched computers, and my Ubuntu laptop gives the second, while the third is from my Debian server. I didn't actually write the code, it's all over the Internet in the same exact form. – SkylarMT Jun 25 '13 at 23:17
  • 2
    confirmed. if you have a 64 bit machine, then this will be fine. Besides... who of us will have 32 bit only machines still running in the year 2038? – jrg Jun 27 '13 at 0:57
  • 1
    I went looking for this to illustrate the 2038 problem to a coworker, and 2 years after making the above comment, I have very little doubt that in 2038 we will have 32 bit machines that will fail. Ah, youthful optimism. – jrg Aug 5 '15 at 13:14
  • @James, maybe some unwittingly. There will probably be embedded 32 bit Linux in IoT devices around then, unpatched. End of the world? No. Some trouble in some places? Definitely. – Prof. Falken contract breached Mar 22 '17 at 12:42
3

I wrote and published a short paper on this back in 1996. This included a short C program to demonstrate it. I also had emails with David Mills about similar issues with NTP- the Network Time Protocol. On my Ubuntu 14.04 64-bit laptop the perl code did not exhibit the limitation so the underlying 64-bit libs must have been modified.

However, running my long-ago test code does show the time wraps back to the UNIX Epoch. So not all is well with the 32-bit code from the past.

My 1996 paper, The UNIX time will run out in 2038! has been on my website since around 2000. A variant of this titled "UNIX Time" was published in 1998 in "Year 2000 Best Practices for Y2K Millennium Computing" ISBN 0136465064.

| improve this answer | |
2

64-bit Linux is ready, at least if you are talking about the core OS interfaces (individual applications can of course still screw it up). time_t is traditionally defined as an alias for "long" and "long" on 64-bit linux is 64-bit.

The situation for 32-bit Linux (and the compatibility layer for 32-bit binaries on 64-bit Linux) is much less rosy. It's broken and fixing it without breaking all existing binaries is not an easy task. A whole bunch of APIs use time_t and in many cases it is embedded as part of data structures, so not only must the APIs be duplicated the data structures they work with must be too.

Even if there is some level of backwards compatibility all binaries that want to get correct time will need to be rebuilt to use the new 64-bit time interfaces.

There has been some work done (see for example https://lwn.net/Articles/643234/ and http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html) but afaict we are still a long way from a full solution. It is not clear whether or not there will ever be general purpose 32-bit distributions that are Y2K38 safe.

| improve this answer | |
  • They are nearly finished now Approaching the kernel year-2038 end game lwn.net/Articles/776435 – Robert Walker Dec 29 '19 at 23:31
  • The kernel is only one part of the puzzle, glibc and the distributions also have a bunch of work to do. – Peter Green Dec 30 '19 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.