Panic - Y2k38 Bug!!!


Results 1 to 14 of 14

Thread: Panic - Y2k38 Bug!!!

  1. #1
    Join Date
    Jul 2001
    Location
    Fife, Scotland
    Posts
    1,794

    Panic - Y2k38 Bug!!!

    Try pasting the following code into a standard Linux file, change permissions so it's executable and then run it:

    Code:
    #!/usr/bin/perl
    #
    # I've seen a few versions of this algorithm
    # online, I don't know who to credit. I assume
    # this code to by GPL unless proven otherwise.
    # Comments provided by William Porquet, February 2004.
    # You may need to change the line above to
    # reflect the location of your Perl binary
    # (e.g. "#!/usr/local/bin/perl").
    # Also change this file's name to '2038.pl'.
    # Don't forget to make this file +x with "chmod".
    # On Linux, you can run this from a command line like this:
    # ./2038.pl
    use POSIX;
    # Use POSIX (Portable Operating System Interface),
    # a set of standard operating system interfaces.
    $ENV{'TZ'} = "GMT";
    # Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
    for ($clock = 2147483641; $clock < 2147483651; $clock++)
    {
        print ctime($clock);
    }
    # Count up in seconds of Epoch time just before and after the critical event.
    # Print out the corresponding date in Gregorian calendar for each result.
    # Are the date and time outputs correct after the critical event second?
    We're all going to DIE!!!

    (Well, maybe in 31 years time... by which time they MIGHT have found a solution to the problem).

    Sorry to be a misery, but:

    THE WORLD'S GOING TO END!!!

    James

    PS. Your thoughts???
    Last edited by Satanic Atheist; 07-26-2007 at 02:45 PM. Reason: Messed up HTML tags
    -----------------------------
    UseLinux.net
    -----------------------------

    perl -e 'use Math::Complex;$|=1;for$r(0..24){for$c (0..79){$C=cplx(($c/20.0)-3.0,-($r/12.0)+1.0);$Z= cplx(0,0);for($i=0;($i<80)&&(abs($Z)<2.0);$i++){$Z =$Z*$Z+$C;}print$i>=80?"*":" ";}print"\n";}'

  2. #2
    Join Date
    Oct 2002
    Location
    AZ, USA
    Posts
    110
    Been There Done That. If you are bothered by it I suggest setting up some date windoing routines, or start hacking on a larger date field, say 64 bit in the kernal.
    At least 1 mainframe OS will hit the date to zero in 2028.

  3. #3
    Join Date
    Jul 2002
    Location
    New Orleans, LA USA
    Posts
    986
    Yea, do a google on "Year 2038 problem" and you should get a bunch of returns. The general idea is by 2038 we'll all be using 64 bit(or higher?) computers. I'd say this is a realistic goal in terms of desktop PCs(in whatever form they are by that year), but the big problems will lie with embedded devices and old databases that have the signed 32bit date built in. We still have countless computers up running DOS based(or like) software using dial-up connections, simply because there isn't a merit for the newer technology based on their function.
    "Whenever you find yourself on the side of the majority, it's time to pause and reflect."

    -Mark Twain

  4. #4
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,947
    So what's the problem?

    Code:
    $ ./2038.pl
    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:08 2038
    Tue Jan 19 03:14:09 2038
    Tue Jan 19 03:14:10 2038
    $
    I don't get it...

    (Silly people still running 32-bit. JRefL5 -- already been done. 64-bit CPU kernels (at least kernels for AMD64/new-Intel-64-bit) already have a 64-bit time_t, so they won't overflow.)

  5. #5
    Join Date
    Jul 2001
    Location
    Fife, Scotland
    Posts
    1,794
    I ran that code on my Intel Core2 Duo server which, I know is capable of 64-bit, but I'm running it at 32-bit since the Debian 64-bit install didn't work and it still fell over.

    I just hope that by the time I have to face the world ending I won't be running that machine anymore and will probably have disappeared 2038 years into the past (give or take a few nanoseconds) from my quantum computer.

    Dang, time to update my life insurance - must include "eaten by dinosaur"... (Just to be on the safe side).

    Seriously, though, is using 64-bit registers enough to overcome this problem? I don't know how Unix time works yet - haven't researched it enough. I don't particularly want to use 64-bit for at least another year until enough software is recompiled for my apt setup.

    James
    -----------------------------
    UseLinux.net
    -----------------------------

    perl -e 'use Math::Complex;$|=1;for$r(0..24){for$c (0..79){$C=cplx(($c/20.0)-3.0,-($r/12.0)+1.0);$Z= cplx(0,0);for($i=0;($i<80)&&(abs($Z)<2.0);$i++){$Z =$Z*$Z+$C;}print$i>=80?"*":" ";}print"\n";}'

  6. #6
    Join Date
    Oct 2002
    Location
    AZ, USA
    Posts
    110
    BWKAZ, Thats what I get for not testing SA's script.

    SA. some rough math places 64 bit signed some 2E11 years out I'm not even thinking about that time frame

    Another James

  7. #7
    Join Date
    Jul 2005
    Posts
    121
    Why do I get 1901?

    Code:
    [conny@fester]$ ./time.pl
    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
    Edit: lol...why would it be the end of the world is a better question I guess?
    Last edited by con; 07-27-2007 at 06:06 AM.

    Kubuntu 8.10
    Asus M2N-VM DVI
    ATI Radeon 3850

  8. #8
    Join Date
    Jul 2002
    Location
    New Orleans, LA USA
    Posts
    986
    1901 is returned because the signed 32-bit time_t overflowed. The proposed solution is to use a signed 64-bit time_t which will have a wraparound of 290 billion years.

    So, if humanity can actually not destroy itself or be whipped out by some other entity in that time period, Satanic Atheist will reincarnate into another host and make another post about the end of the world because his 64-bit machine will crash from another time_t overflow anomaly~
    "Whenever you find yourself on the side of the majority, it's time to pause and reflect."

    -Mark Twain

  9. #9
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,947
    Quote Originally Posted by Satanic Atheist
    I ran that code on my Intel Core2 Duo server which, I know is capable of 64-bit, but I'm running it at 32-bit since the Debian 64-bit install didn't work and it still fell over.
    It fell over because you're running a 32-bit kernel, a 32-bit glibc, and a 32-bit Perl. Only a system running a 64-bit kernel can use a 64-bit time_t. (Or more appropriately, 64-bit kernel, glibc, and Perl. But the kernel's required first.)

    Seriously, though, is using 64-bit registers enough to overcome this problem?
    Yes, but only indirectly. On a kernel that will allow the use of 64-bit registers, the size of a time_t (the type of variable used to represent time, in seconds since midnight, January 1, 1970) is almost always 64 bits; the same size as the registers. So the time values won't overflow in 2038.

    (I believe 32-bit programs get a compatibility layer in the kernel that uses the old 32-bit time_t, though. So if you run that perl script under a 32-bit Perl binary, it'll still break (I just tried it under my perl-32; I should note that I have both perl-32 and perl-64, with perl a symlink to perl-64). You have to move to a pure64 setup (no 32-bit stuff at all) to completely avoid overflows.)

    I don't know how Unix time works yet - haven't researched it enough.
    Depends on what you're looking at. There are actually several different interfaces to get "the current time", because it can come in several different formats. The most common (and the format used inside the kernel) is a time_t, which is the number of seconds that have passed since midnight, January 1, 1970, UTC. That's pretty much it.

    If your time_t doesn't have enough bits (and it's been too many seconds since January 1, 1970), then it'll overflow. If your time_t is 64 bits, then it won't overflow for ... way longer than your computer will be around.

    I don't particularly want to use 64-bit for at least another year until enough software is recompiled for my apt setup.
    Oh, another year's fine. Just don't let that one year stretch out to 31 years.

  10. #10
    Join Date
    Jul 2001
    Location
    Fife, Scotland
    Posts
    1,794
    Hmmm, I just realised how daft my post was about 32-bit Debian on a 64-bit machine... I really need to cut down my caffeine/alcohol intake :-)

    Anyway, why do we have Unix time? Other operating systems don't seem to need it so why does Unix? Is it just a hangover from the past that never got removed/updated but instead became sort of hereditary for Unix and similar systems?

    Lastly, what's the danger that they'll "forget" to fix this one for 30 years and then remember about it and panic like mad? Actually, does this situation sound familiar...

    James
    -----------------------------
    UseLinux.net
    -----------------------------

    perl -e 'use Math::Complex;$|=1;for$r(0..24){for$c (0..79){$C=cplx(($c/20.0)-3.0,-($r/12.0)+1.0);$Z= cplx(0,0);for($i=0;($i<80)&&(abs($Z)<2.0);$i++){$Z =$Z*$Z+$C;}print$i>=80?"*":" ";}print"\n";}'

  11. #11
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,947
    Quote Originally Posted by Satanic Atheist
    Anyway, why do we have Unix time? Other operating systems don't seem to need it so why does Unix?
    Other OSes don't have time? That's news to me. Doesn't Windows have a clock?

    (To be clear: The low-level time_t value that you get from the kernel is the basis for everything time-related. It gets converted, yes, but it's the basic time measurement. If Linux didn't have it, then it'd have no concept of time at all, and that would basically cripple it.)

    And other OSes do need it, or something very much like it. It's a PITA to update anything other than a single counter when each second rolls over in the kernel; that counter's value is what gets handed out to userspace as a time_t on Unix. (Because that's in line with the system-transparency goals of Unix.)

    For the last bit: I'd say that since this is already fixed in 64-bit kernels, it's more likely to be forgotten about for the next 30 years -- but only because there's no problem anymore. All you have to do is get new hardware at some point in the next 30 years (basically everything is 64-bit now), and the more time that elapses between now and when you do that, the more memory you'll get on that new machine. And any more memory than around 4GB (depending on the kernel) won't be accessible on a 32-bit OS (unless it uses a bunch of poorly-designed hacked-together interfaces to get at it, but even with that, a single process won't ever be able to use more than 4GB).

  12. #12
    Join Date
    Jan 2003
    Location
    Zurich, Switzerland
    Posts
    2,658
    Quote Originally Posted by Satanic Atheist
    Lastly, what's the danger that they'll "forget" to fix this one for 30 years and then remember about it and panic like mad?
    Trust noone. Fortify your basement. Install big tanks for fresh water. Buy spam and other canned food. Get used to the taste of "atomic bread" (the Swiss military used to have break soaked with pure alcohol so it can be almost indefinitely stored in case of a nuclear war. Before you could eat it, you hat to let it ventilate in the fresh air). Train evacuation routines with your wife and kids. Gee, you've been in a British Regiment yourself, so why am I telling you all this?

    Quote Originally Posted by con
    Edit: lol...why would it be the end of the world is a better question I guess?
    Just imagine that over night no financial information isn't available anymore. It starts with your savings, continues with governmental agencies doing taxes, and ends with stock markets being down. Now add to this scenario power stations and water pumps controlled by computers and you get the picture. OTOH, not paying taxes may not be that bad.

    "What can be said at all can be said clearly, and what we cannot talk about we must pass over in silence."

    Tractatus Logico-Philosophicus by Ludwig Wittgenstein (1889-1951)

  13. #13
    Join Date
    Jul 2001
    Location
    Fife, Scotland
    Posts
    1,794
    One of the arguments for the original Y2K bug was with nuclear plants - the system that controls the insertion and removal of control rods is (usually) an embedded UNIX system that used the old system of storing the year in 2 digits. The threat proposed was that if it timed itself to remove/insert a rod after Y2K then it may not do it either causing an unexpected nuclear shutdown or meltdown.

    Anyway, I said that other OSes don't seem to use UNIX time, not that they don't use time at all. I don't know what they use, but you'll never see the option to show the UNIX time on Windows for example, it only shows the "real" time.

    So, my question is, why is midnight Jan 1st 1970 such an important time?

    James
    -----------------------------
    UseLinux.net
    -----------------------------

    perl -e 'use Math::Complex;$|=1;for$r(0..24){for$c (0..79){$C=cplx(($c/20.0)-3.0,-($r/12.0)+1.0);$Z= cplx(0,0);for($i=0;($i<80)&&(abs($Z)<2.0);$i++){$Z =$Z*$Z+$C;}print$i>=80?"*":" ";}print"\n";}'

  14. #14
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,947
    Quote Originally Posted by Satanic Atheist
    Anyway, I said that other OSes don't seem to use UNIX time, not that they don't use time at all.
    But all that the time_t value is (...which I believe is what you're referring to as "Unix time", since I've never heard that term before), is just the number of seconds since 1/1/1970, UTC. It is the time on a Unix system. If Unix systems didn't have Unix time, they wouldn't have any time (and conversely, if they used a different standard for time, then that standard would presumably be "Unix time", and we'd be discussing it instead).

    I don't know what they use, but you'll never see the option to show the UNIX time on Windows for example, it only shows the "real" time.
    No, it only shows what it believes to be the local time. Linux boxes show you this too, when you use "date" and you have $TZ set properly -- plus most desktops also have a clock applet thingy that shows the current time. But all of that is based off the current time_t UTC value.

    So I guess what I'm saying is, I have no idea what you mean by "Unix time" for sure, so I really don't get what you're asking...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •