No announcement yet.

C/C++ Programmers : Did you know ?

  • Filter
  • Time
  • Show
Clear All
new posts

    C/C++ Programmers : Did you know ?

    Hey, Don't despair cuz you don't know Cobol.
    Well C/C++ Programmers have something to look forward to now.
    This week I got this email from my Manager.
    After digging thru my C Manuals, I suspect what the email reads is more than true. Here goes :

    Daniel Bossa
    02/08/99 11:10 AM

    To: Y2K - Administrators, Y2K - Authors, Y2K - Executives, Y2K - Internal
    Systems, Y2K - Owners, Y2K - Readers, Y2K - Team MPower, Y2K - Team
    Multipath, Y2K - Team Ops/Network/Service, Y2K - Team SMS,
    Subject: Year 2038 bug ???

    All Ready for 2000 and the Euro?
    What About 2038?

    First it was Y2K. Then the Euro conversion. And now, as if the Y2K and Euro problems weren't bad enough, there's the year 2038 bug. Dr. Bafil got a letter from Mahmoud Saleh alerting him (reminding him, actually) of a similar problem that will face C and C++ programmers in coming years: we can call it the Y2.038K bug.

    The problem stems from the common definition of the time_t as an integer containing the number of seconds since midnight,
    January 1, 1970. Most C/C++ runtime libraries define time_t as a long int. On most systems, long int is 32 bits, which means that we've got a range of 2^31-1 (2,147,483,647) seconds
    until sometime on January 18, 2038.

    (Assuming Dr. Bafil's Windows CE Palm-size PC has it right, that's a Monday. Figures.)

    Since the number is signed, when the clock rolls over the time will be a very large
    negative number, giving us a time warp of a little over 136 years...
    we'll flip back to sometime late in December, 1901. (Good thing that
    time_t isn't a 31-bit unsigned number, or it would have been back to the '70s for
    everyone. You'd have had to get your leisure suits ready 'cuz you'd be catching Boogie Fever and Nixon would be President again. Four more years indeed!)
    For reason, ruling alone, is a force confining - and passion, unattended, is a flame that burns to its own destruction - Khalil Gibran

    Yup dude is right...quote below is from an email exchange last semester between my prof and and class. Also see RFC 868 (Time Protocol)

    "Time will run out in 2036 for the internet, but 2038 for windows (although in 2037 and 2038, internet time will roll over, yielding
    bad values from a windows client). the new "Y2K+36" problem!"


      Hmm. I suppose the time function library could be re-written. Perhaps they could solve it for the short term by calculating the number of seconds from a different point.

      We have to also realize that by that time we might not be using C++. Object Oriented programming will probably be superceded twice or more. Perhaps the system processors of that time would be able to cope with integers longer than the current long integer limits.

      How does Java cope with this? ANybody have any ideas?