Please create an account to participate in the Slashdot moderation system


Forgot your password?
Bug Software Linux

Y2K38 Watch Starts Saturday 542

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."
This discussion has been archived. No new comments can be posted.

Y2K38 Watch Starts Saturday

Comments Filter:
  • Hmmmmmm (Score:2, Funny)

    by LithiumX ( 717017 )
    I spell profits on the wind...

    *sniffs himself*

    Yeah, it's the wind.
  • by ucblockhead ( 63650 ) on Tuesday January 15, 2008 @04:44PM (#22056772) Homepage Journal
    I plan on making a mint using my mad C skillz in 2036 and 2037, just like all those Cobol guys who came out of retirement in 1998.
  • by Actually, I do RTFA ( 1058596 ) on Tuesday January 15, 2008 @04:44PM (#22056774)
    I can get a thirty-year $250,000 loan with monthly payments of -$1,200.
  • by corsec67 ( 627446 ) on Tuesday January 15, 2008 @04:47PM (#22056836) Homepage Journal
    And, wouldn't 50 years or longer loan terms have shown this before now?
    • It's a dumfuk comment in the summary. If you're calculating payments on a thirty-year loan, you sure as heck don't convert all your dates to seconds since the epoch ("Unix time"). What would be the point? You don't compound your interest by the second, and if a payment is due on such-and-such a date, you don't specify the exact second it's due.

      I expect loan software converts dates and lengths of time if at all to months, that being the typical interval when you compound interest. So even on 32-bit Unix
  • by Hatta ( 162192 ) on Tuesday January 15, 2008 @04:48PM (#22056846) Journal
    Remind me again when it's 30 minutes.
  • Envy (Score:5, Funny)

    by argmanah ( 616458 ) * <{argmanah} {at} {}> on Tuesday January 15, 2008 @04:50PM (#22056928)
    I envy the programmers who had the foresight to program their application using a 2 digit year field. They won't have to worry have to worry about this problem until 2099, and by then we won't be using the same systems we do today anyways!
    • Strangely enough I got hit by a Y2K bug last week which will not get fixed for several months. Some idiot decided that 0000 would be good for a permanent licence - which means all the new permanant licences for a product my company is using expired on 1/1/2000. The work around the vendor approved is to disable the licence checking software entirely for the six to nine months before a solution is released. Don't you love expensive closed source abandonware?
  • by jconley ( 28741 )
    Everyone's getting 50 year loans now anyhow, there won't be a problem with the date calc.

    There may be an overflow when they calculate how much interest they are paying though...
  • My date of birth (Score:5, Interesting)

    by nogginthenog ( 582552 ) on Tuesday January 15, 2008 @04:51PM (#22056940)
    Is 123456789, Unix time. No shit. 29 Nov 1973. Guess I'm a confirmed geek then?
    • by scaverdilly ( 902859 ) on Tuesday January 15, 2008 @05:08PM (#22057248)
      Yeah, but 1234567890 comes just short of Feb 14th in a year (Fri, 13 Feb 2009 23:31:30 UTC).
      It just goes to show that true geeks will only ever almost get close enough to women for romanitc encounters.
    • Re: (Score:3, Funny)

      by Compholio ( 770966 )

      [My date of birth] Is 123456789, Unix time. No shit. 29 Nov 1973. Guess I'm a confirmed geek then?
      I'm sure your mom appreciates that just as much as having you at 11:30 PM GMT.
    • Re: (Score:3, Funny)

      by choongiri ( 840652 )
      My birthday is January 19th. Does that mean I'm going to expire due to some kind of horrible fatal error on my 57th birthday?
    • Re: (Score:3, Funny)

      by cashman73 ( 855518 )
      Holy shit! That's the same combination that I have on my luggage! =)
  • by edwardpickman ( 965122 ) on Tuesday January 15, 2008 @04:52PM (#22056958)
    So long as it wipes out my 30 year loan I don't have a problem here. Now if we can get this to work on my five year car loan......
  • by Malevolent Tester ( 1201209 ) on Tuesday January 15, 2008 @04:55PM (#22057016) Journal
    Is this going to affect the Duke Nukem Forever release?
  • By 2038 I'd expect everyone to be on 64-bit processors, if not 128- or 256-bit hardware. Even at 64-bits, I won't live long enough for that clock to run out, although it will make some of my favorite hobbies (counting the number of atoms in the galaxy) a lot easier.
  • by Gordonjcp ( 186804 ) on Tuesday January 15, 2008 @05:02PM (#22057168) Homepage
    VMS has been Y10K-compliant for over a decade.
    • by ewilts ( 121990 ) on Tuesday January 15, 2008 @05:28PM (#22057504) Homepage
      > VMS has been Y10K-compliant for over a decade.

      It's much better than that. It's mostly DCL that has the year 9999 issue. For those of you who like history lessons and how to design real operating systems (and customer support, back when it actually existed), read this article:

        38 Why Is Wednesday November 17, 1858 The Base Time For VAX/VMS?



      SOURCE: Customer Support Center/Colorado Springs


      Why is Wednesday, November 17, 1858 the base time for VAX/VMS?


      November 17, 1858 is the base of the Modified Julian Day system.

      The original Julian Day (JD) is used by astronomers and expressed in days
      since noon January 1, 4713 B.C. This measure of time was introduced by
      Joseph Scaliger in the 16th century. It is named in honor of his father,
      Julius Caesar Scaliger (note that this Julian Day is different from the
      Julian calendar named for the Roman Emperor Julius Caesar!).

      Why 4713 BC? Scaliger traced three time cycles and found that they were
      all in the first year of their cyle in 4713 B.C. The three cycles are 15,
      19, and 28 years long. By multiplying these three numbers (15 * 19 * 28
      = 7980), he was able to represent any date from 4713 B.C. through 3267 A.D.
      The starting year was before any historical event known to him. In fact,
      the Jewish calendar marks the start of the world as 3761 B.C. Today his
      numbering scheme is still used by astronomers to avoid the difficulties of
      converting the months of different calendars in use during different eras.

      So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858.
      The Modified Julian Day uses the following formula:

            MJD = JD - 2,400,000.5

      The .5 changed when the day starts. Astronomers had considered it more
      convenient to have their day start at noon so that nighttime observation times
      fall in the middle. But they changed to conform to the commercial day.

      The Modified Julian Day was adopted by the Smithsonian Astrophysical Obser-
      vatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites
      with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was
      launched. The Julian day was 2,435,839 on January 1, 1957. This is
      11,225,377 in octal notation, which was too big to fit into an 18-bit field
      (half of its standard 36-bit word). And, with only 8K of memory, no one
      wanted to waste the 14 bits left over by keeping the Julian Day in its own
      36-bit word. However, they also needed to track hours and minutes, for which
      18 bits gave enough accuracy. So, they decided to keep the number of days in
      the left 18 bits and the hours and minutes in the right 18 bits of a word.

      Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as
      large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven
      centuries. Using only 17 bits, the date could possibly grow only as large as
      131,071, but this still covers 3 centuries, as well as leaving the possibility
      of representing negative time. The year 1858 preceded the oldest star catalog
      in use at SAO, which also avoided having to use negative time in any of the
      satellite tracking calculations.

      This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and
      VAX/VMS. Given this base date, the 100 nanosecond granularity implemented
      within VAX/VMS, and the 63-bit absolute time representation (the sign bit must
      be clear), VMS should have no trouble with time until:

            31-JUL-31086 02:48:05.47

      At this time, all clocks and time-keeping operations within VMS will suddenly
      stop, as system time values go negative.

      Note that all time display and manipulation routines within VMS allow for
      only 4 digits within the 'YEAR' field. We expect this to be corrected in
      a future release of VAX/VMS sometime prior to 31-DEC-9999.
    • As a coincidence, nobody has actually used VMS in over a decade.
  • End of the world (Score:3, Insightful)

    by timmarhy ( 659436 ) on Tuesday January 15, 2008 @05:04PM (#22057196)
    Lots of over priced consultants will charge a fortune to fix a problem we negated years ago, then when the day comes and nothing happens they will claim it's a resounding success.
  • Incorrect.... (Score:5, Informative)

    by gweihir ( 88907 ) on Tuesday January 15, 2008 @05:07PM (#22057232)
    Older flavours of Unix will wrap-around on 32 bit int. More modern systems use time_t instead of int and may or may not be affected by the problem. time_t can be unsigend (which gives another 68 years) or long long int/long long unsigned (which are both 64 bit long). In any case, fixing the basis library and recompileing is enough for properly implemented software.
  • by Anonymous Coward on Tuesday January 15, 2008 @05:17PM (#22057394)
    I don't give a shit. And I mean that in the most literal, non-idiomatic way. If I had a pile of turds in my back yard, and you were to walk up to me and say, "Excuse me, sir, if you would let me relieve you of one of these useless pieces of feces I could guarantee a resolution to the Y2K38 computer issue," I would simply reply, "I'm sorry, but those are my shits, and I'm not giving one."

    • by Chris Burke ( 6130 ) on Tuesday January 15, 2008 @07:20PM (#22059230) Homepage
      I don't give a shit. And I mean that in the most literal, non-idiomatic way. If I had a pile of turds in my back yard, and you were to walk up to me and say, "Excuse me, sir, if you would let me relieve you of one of these useless pieces of feces I could guarantee a resolution to the Y2K38 computer issue," I would simply reply, "I'm sorry, but those are my shits, and I'm not giving one."

      You are clearly a person who has their shit together.
  • by wytcld ( 179112 ) on Tuesday January 15, 2008 @05:21PM (#22057440) Homepage
    Most often when I've set up date fields in databases, I've used the YYYYMMDD format (e.g. 20080115, YYMMDDHHMMSS of course is also an option). The simple regex to construct it and read it is barely more code than translating in and out of Unix timestamps, and there's the great advantage that the dates are human-readable in the tables, and ad hoc queries are easily constructed. So I should be good until the year 10,000. Am I the only one? It's always seemed the obvious best way to do it.
  • by zippthorne ( 748122 ) on Tuesday January 15, 2008 @05:29PM (#22057524) Journal
    This is nothing like the two-digit date problem of Y2K. The conversion process shouldn't be anywhere near as complicated, since 32bit dates are just an arbitrary subset of a larger bit-count dates. There are really only two cases, signed and unsigned, and casting things into larger containers isn't exactly all that difficult: if unsigned, stick a bunch of zeros on the front. If signed, stick a bunch of zeros on the front, then swap the previous MSB with the new MSB.

    Furthermore, C programmers haven't exactly become a rare commodity in the intervening time like with COBOL. Y2K wasn't a problem, so why should we expect Y2K+38 to be a problem?
  • by quarkie68 ( 1018634 ) on Tuesday January 15, 2008 @05:37PM (#22057666) Homepage
    # (or wherever your camel lives)
    #Copyleft (just joking!) Georgie
    use POSIX;
    use strict;

    $ENV{'TZ'} = "GMT";
    # GMT for preference
    print "And the transition will be like...\n";
    for (my $clock = 2147483646; $clock < 2147483650; $clock++)
        print ctime($clock);

    chomp(my $conclusion=ctime(2147483650));
    if ( $conclusion=~ /1901$/) {
            print "Which means that you are bugged by 32 bits. We have 64 bit processors and structures now you know!\n";} else {
            print "You will survive for now. Go and get a beer. \n";}
  • by davido42 ( 956948 ) on Tuesday January 15, 2008 @05:57PM (#22057986) Homepage Journal
    Why would anyone be using an OS written for scientists? They're all weird and stuff.
  • by spydink ( 256993 ) on Tuesday January 15, 2008 @06:18PM (#22058306) Homepage
    2038 is just the tip of the iceberg!!!

    Significant dates []
  • Y2K38? (Score:3, Insightful)

    by STrinity ( 723872 ) on Tuesday January 15, 2008 @06:36PM (#22058550) Homepage
    "Y2K" was a stupid appellation to begin with, but at least it saved one character compared to "2000." "Y2K38" on the other hand is one character longer than just 2038. You're just wasting electrons writing it the other way.
  • by todslash ( 1025980 ) on Wednesday January 16, 2008 @08:11AM (#22065004)

    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 []. 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;
    printf ("Time now: %s", asctime (gmtime (&t1)));
    printf ("Add 100 seconds: %s", asctime (gmtime (&t2)));
    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.

Forty two.