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?
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?
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 thattm_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 thantime_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: