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?

Jorge Castro
  • 71,754
ThePiercingPrince
  • 688
  • 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
  • @Piskvor you are making an implicit assumption that such devices have an operating life that will exceed 25 years of continuous operation. – hmayag May 24 '13 at 13:08
  • 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
  • @Piskvor Yes, I see your point. Infrastructure components like those you describe can certainly provide a valid reason for concern. – hmayag May 24 '13 at 20:49
  • Just 32-bit ones. Or at least, ones that use 32-bit timestamps. – Aaron Franke Dec 12 '16 at 10:22

4 Answers4

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:

Community
  • 1
Radu Rădeanu
  • 169,590
  • 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
  • @Nane Are you a programmer? A clock will not fail from the viewpoint of a watchmaker. Don't you think that the programmers didn't knew about this problem from the beginning? They made it to be like this (for this i said it will work as expected). – Radu Rădeanu May 24 '13 at 15:28
  • 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 08:10
  • 2
    @gertvdijk "Is the" current/actual "Linux kernel or Ubuntu ready to handle dates after this?" – Radu Rădeanu May 28 '13 at 08:17
  • This only affects 32-bit systems, right? –  Apr 03 '16 at 18:23
  • 1
    In C, adding 1 to INT_MAX is undefined behavior. – Damian Yerrick Jul 31 '17 at 17:34
  • If your internet controlled lightbulb fails to connect to it's master server because it thinks the TLS certificate is "not yet valid" you will consider it broken. – Peter Green May 14 '18 at 15:15
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
johnf
  • 896
SkylarMT
  • 71
  • 1
  • 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 00: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 05 '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 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.

muru
  • 197,895
  • 55
  • 485
  • 740
oldunixguy
  • 31
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.

Peter Green
  • 1,841
  • 1
  • 12
  • 15