Slashdot Mirror

← Back to Stories (view on slashdot.org)

Y2K38 Watch Starts Saturday

Posted by kdawson on from the not-a-good-day-for-a-loan dept.

Jon Masters writes "I just wanted to remind everyone that Saturday, January 19th 2008 will mark the beginning of the 30-year countdown to the Y2K38 bug, when Unix time will overflow 32 bits. Some 30-year loan calculation software might start having problems with this over the weekend."

6 of 542 comments (clear)

  1. My date of birth by nogginthenog · · Score: 4, Interesting

    Is 123456789, Unix time. No shit. 29 Nov 1973. Guess I'm a confirmed geek then?

  2. Re:The answer is 64! by 91degrees · · Score: 3, Interesting

    They might... After all, transistor computers were up to 32 and 36 bits before the first 4-bit microprocessor was introduced. It is possible that a revolutionary new concept in processing will result in an insanely fast processor but technological limitations will force it to only be 8 bits.

  3. Re:The answer is 64! by thegrassyknowl · · Score: 5, Interesting

    Put simply, a lot of software is poorly written and uses int as synonymous with time_t (or somesuch). The two are often interchanged by programmers; particularly those with a Windows background who can't find CTime (or whatever it's called) on non-Windows platforms.

    Moving to 64-bit machines won't fix all the magic 32-bit binaries out there but software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int.

    Of course, I've seen a lot dumber bugs than ignoring to use the operating system's time structures and methods for dealing with time so I don't doubt that there are some bugs that actually will need some serious considerations made.

    I guess it's a fault of the Unix people from way back. They made this epoch thing and used a 32-bit number to store the number of seconds since it. I guess they were assuming that all their software would have been replaced by something better on bigger machines. They shouldn't have written such reliable software and then maybe some of it would have been replaced by now ;)

    --
    I drink to make other people interesting!
  4. Re:What about the new 40 and 50 year loans? by kcornia · · Score: 4, Interesting

    40 and 50 year loans are really 30 year loans that will be refactored (or rewritten or reset, whatever terminology they used) at 10 and 20 years left respectively. From my recollection based on work in subprime IT for a few years, it has to do with laws that limit the life of a loan to 30 years or something.

    Regardless, 40 and 50 year loans are right up there with negative amortization adjustable loans. HORRIBLE ABUSE OF TEH SYSTEM. If you have to stretch that far to get into a house, rent a fucking apartment and save up some money for cryin' out loud.

    This credit crunch is a good thing, we as consumers need to get off the endless debt teat.

  5. Re:And other things.. by Gospodin · · Score: 4, Interesting

    11/9 was just big because it was in the US. Anti-US sentiment aside, the US is simply a more influential country than any of those affected by the Tsunami. US has very a powerful media and politic, so of course its going to be well covered.

    9/11 was big because it was caused by people. The tsunami was caused by nature. Comparing responses to them is like comparing responses to a murder versus a heart attack.

    --
    ...following the principles of Heisenburger's Uncertain Cat...
  6. Averages causing overflows by todslash · · Score: 3, Interesting

    It's not a big issue and as long as programmers are aware then hopefully it will be avoided.

    But there are pitfalls out there now which naive programming may fall into.

    I came across this one at http://www.2038bug.com/. We hit the 31st bit of POSIX time in 2004. That means that if you add together any two current times, for example when taking an average, then you will overflow a 32 bit signed integer.

    Apologies for code quality but this artificial example hopefully shows the issue:

    #include <stdlib.h>
    #include <stdio.h>
    #include <unistd.h>
    #include <time.h>
    int main ()
    {
    time_t t,t1,t2;
    struct timeval tnow;
    gettimeofday(&tnow,NULL);
    t1=tnow.tv_sec;
    printf ("Time now: %s", asctime (gmtime (&t1)));
    t2=t1+100;
    printf ("Add 100 seconds: %s", asctime (gmtime (&t2)));
    t=(t1+t2)/2;
    printf ("Average: %s", asctime (localtime (&t)));
    return 0;
    }

    gives the following on my x86 Linux system:

    Time now: Wed Jan 16 11:43:18 2008
    Add 100 seconds: Wed Jan 16 11:44:58 2008
    Average: Fri Dec 29 08:30:00 1939

    It's easy to fix by casting to 64 bit or dividing first but there may be similar examples hiding away in old code which are less easy to spot.