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

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.

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

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.