Will the Linux clock fail at January 19, 2038 3:14:08?

Question

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?

Answer 1

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:

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:

So there is nothing to be concerned about this problem.

More about:

• Year 2038 problem - Wikipedia.
• End of Time (Unix) - Numberphile.

Answer 2

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

Answer 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.

Answer 4

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.