Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Wednesday January 22 2020, @05:18PM   Printer-friendly
from the here-we-go-again dept.

Steven Bellovin, Professor of Computer Science at Columbia University writes briefly with a concrete example of how the Y2038 threat works.

[...] just as with Y2K, the problems don't start when the magic date hits; rather, they start when a computer first encounters dates after the rollover point, and that can be a lot earlier. In fact, I just had such an experience.

A colleague sent me a file from his Windows machine; looking at the contents, I saw this.

$ unzip -l zipfile.zip
Archive: zipfile.zip
Length Date Time Name
——— ——— ———
2411339 01-01-2103 00:00 Anatomy...
——— ———

Look at that date: it's in the next century! (No, I don't know how that happened.) But when I looked at it after extracting on my [MacOS] computer, the date was well in the past:

$ ls -l Anatomy...
-rw-r-r-@ 1 smb staff 2411339 Nov 24 1966 Anatomy...

Huh?

After a quick bit of coding, I found that the on-disk modification time of the extracted file was 4,197,067,200 seconds since the Epoch. That's larger than the limit! But it's worse than that. I translated the number to hexadecimal (base 16), which computer programmers use as an easy way to display the binary values that computers use internally. It came to FA2A29C0. (Since base 16 needs six more digits than our customary base 10, we use the letters A–F to represent them.) The first "F", in binary, is 1111. And the first of those bits is the so-called sign bit, the bit that tells whether or not the number is negative. The value of FA2A29C0, if treated as a signed, 32-bit number, is -97,900,096, or about 3.1 years before the Epoch. Yup, that corresponds exactly to the November 24, 1966 date my system displayed. (Why should +4,197,067,200 come out to -97,900,096? As I indicated, that's moderately technical, but if you want to learn the gory details, the magic search phrase is "2's complement".)

While attention is paid to desktops and servers, they are easy to replace and have very short lifetimes. In contrast embedded systems should be receiving special action already since they are seldomly or never updated and have lifespans measured in decades.

Previously:
Reducing Year 2038 Problems in curl (2018)
The Time Is... 1500000000 (2017)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Mykl on Wednesday January 22 2020, @09:13PM (5 children)

    by Mykl (1112) on Wednesday January 22 2020, @09:13PM (#947017)

    ...but have any distros moved the system date to a 64-bit integer yet?

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Informative) by Anonymous Coward on Wednesday January 22 2020, @11:59PM (3 children)

    by Anonymous Coward on Wednesday January 22 2020, @11:59PM (#947105)

    Post C11, it should be a Real [cppreference.com].

    • (Score: 2) by jb on Thursday January 23 2020, @05:38AM (2 children)

      by jb (338) on Thursday January 23 2020, @05:38AM (#947259)

      Post C11, it should be a Real [cppreference.com].

      A floating-point representation of time? No thanks, with timestamps accuracy matters far more than precision.

      • (Score: 2) by maxwell demon on Thursday January 23 2020, @02:34PM (1 child)

        by maxwell demon (1608) on Thursday January 23 2020, @02:34PM (#947402) Journal

        A floating-point representation of time? No thanks, with timestamps accuracy matters far more than precision.

        “Real” does not imply floating point; also integer types are real types. Note that it replaced the former “arithmetic” which also didn't rule out, but also didn't imply floating point.

        My guess is that this is related to the introduction of complex number types which would also be included in “Arithmetic”. You don't want the time to be stored in complex number variables.

        Anyway, storing time in floating point isn't that bad if the floating point type is large enough. For example, the IEEE double has a 52 bit mantissa (this doesn't include the sign bit), therefore it can represent all numbers up to 252 exactly (note that there's no “−1” missing, the smallest positive integer that cannt be represented exactly is 252+1). That is, the first second that cannot be represented exactly would be more than 142 million years after the epoch. And for the next about 142 thousand years, times can be stored accurately down to the millisecond.

        I think it is a safe bet that until then, no current system will still be in use.

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 2) by maxwell demon on Thursday January 23 2020, @02:44PM

          by maxwell demon (1608) on Thursday January 23 2020, @02:44PM (#947411) Journal

          Correction: The mantissa of IEEE double is 53 bits (although only 52 get stored because the initial one is always 1), therefore I underestimated the maximal times by a factor of 2.

          --
          The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 2) by jb on Thursday January 23 2020, @05:36AM

    by jb (338) on Thursday January 23 2020, @05:36AM (#947255)

    ...but have any distros moved the system date to a 64-bit integer yet?

    Yes, responsible OSes do exist. At least one switched to 64bit time_t way back in 2014 [openbsd.org].