Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: 2038 bug

by Abigail-II (Bishop)
on Apr 11, 2003 at 07:26 UTC ( [id://249828]=note: print w/replies, xml ) Need Help??


in reply to Re: 2038 bug
in thread 2038 bug

You'd make a mistake if you think the 2038 problem will magically resolve itself if time_t is suddenly a 64 bit integer. If it were that simple, wouldn't you think many operating systems already had done so? Some obvious problems:
  • Unless all systems switch from 32 bit time_t to 64 bit time_t at the same time, you will have problems when two systems share information (say, using NFS).
  • Modyfing your OS to use a 64 bit time_t doesn't magically change your data. Your file system uses 32 bit timestamps. What do you think would happen if you upgrade your OS to use 64 bit time_t, and it starts assuming your inodes are 12 bytes longer?

2038 is not going to be disaster, unless too many will think that just upgrading to a 64 bit time_t will magically solve all problems. (If it were that simple, we could have let localtime() return a 4 digit year to avoid Y2K.)

Some time ago, I saw the timetable SUN is going to use to introduce a 64 bit time_t value. It's going to be a 10+ year traject.

Abigail

Replies are listed 'Best First'.
Re: Re: 2038 bug
by logan (Curate) on Apr 11, 2003 at 17:36 UTC
    By an odd coincidence, I was watching a Dilbert rerun last night centering around the Y2K bug. The issue was that there was a single ancient mainframe that was linked to all the other more modern machines. Since this one system hadn't been upgraded since the 70s, it was vulnerable to the bug and threatened to destroy them all. The code itself was undocumented, and the only person who might remember where the time-handling code might be was...Wally.

    The rationale given for why it hadn't been upgraded with all the other systems was that there was a short term advantage in cost savings, and by the time the problem surfaced, the executives who made the decisions would be long gone. Sure, it's a Dilbertism, but in the wake of the corporate scandals of 2001, doesn't it ring true?

    Assuming that we'll all be on 64-bit (or 128-bit, or embryonic monkey-brain) processors at some point in the nebulous future is a mistake. Someone out there will decide not to upgrade. Some of my company's customers still use Windows 95. Last year I was at an airport, and the application displaying the arrivals and departures had crashed The terminal was showing a Windows 98 desktop.

    Even if you decide that someone can fix it "later", possibly in the mad dash to fix legacy unix code in Fall of 2037, please document the issue.

    -Logan
    "What do I want? I'm an American. I want more."

Re: Re: 2038 bug
by tachyon (Chancellor) on Apr 11, 2003 at 11:08 UTC

    What I don't really understand is why you could not make time_t an unsigned 4 byte int and thus get another 68 odd years out of it. Leaving aside the problems with C code that expects it to be signed. Why was it unsigned in the first place anyway?

    As you say there are a lot of issues to be resolved. My main point was to abstract the time handling so at least that can of worms is all in the same place which will make it easier to deal with - all other things being equal.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

      tachyon wrote, "What I don't really understand is why you could not make time_t an unsigned 4 byte int and thus get another 68 odd years out of it. Leaving aside the problems with C code that expects it to be signed. Why was it unsigned in the first place anyway?"

      How would you denote my birthdate in 1967, if you use an unsigned forward-pointing integer measured from the epoch of 1970?

      Java standardized on a 64-bit signed time in milliseconds from the same 1970 epoch, which gives them enough range to describe any moment from big bang to big whimper, remain coherent with code that thinks that 1970 was a pretty cool year, and still be a thousand times more precise than the standard unix time. I don't expect time() to follow that standard, but I do think it's safe to say, even considering the usual famous misquote, that 64 bits should be enough for anyone.

      --
      e d @ h a l l e y . c c

        Well, in many areas a millisecond is long. It's a nice ping time to perlmonks.org, but I wouldn't like a millisecond main memory access time. For some physicists, even nanoseconds are not precise enough, they require pico-, femto- or even attoseconds. Unfortunally, with 64 bits and attosecond precision, you only have less than 18.5 seconds as your range.

        Of course, you could always use XS, or Inline::C and use libtai http://cr.yp.to/libtai.html.

        Abigail

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://249828]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (6)
As of 2024-03-19 08:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found