Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: 2038 bug

by tachyon (Chancellor)
on Apr 11, 2003 at 05:19 UTC ( #249809=note: print w/ replies, xml ) Need Help??


in reply to 2038 bug

Put all your time manipulation code in a module called Y2038::Problem ???

Seriously if you abstract your time code to a single location it will be easy to modify. But realistically Y2038 is only an issue if time_t is still a 4 byte int in 2038. It is quite reasonable to expect that 64 bit machines will be the norm and quite possibly 8 byte ints. In Perl there is unlikely to be a major issue as our use of time is abstracted from the raw 4 byte dependent time_t. As a result in Perl 6.01 in 2038 (Oh what a cynic) the basic time() function could quite easily be modified to return an 8 byte int into a Perl scalar and thus there is not real issue provided that the Perl was comiled with 8 byte int support, etc.

The ugly Y2K hack is to assume that times say < 2147483647 / 2 (make it a small a the number of extra years you want to wring out of your code) represents a rollover so proceed accordingly. This potentially gives you another 34 years worth of mileage out of it - assuming that there are not valid dates before 2004 you are processing in 2038 of course. You could facilitate such ugly hacks by putting all time functions in a module. ie

# get the difference between two epoch times and cope with 2038 sub diff_time { my ( $begin, $end ) = @_; # for now all we need is: return $begin - $end; # Jan 19 03:14:07 2038 we have potential rollovers so require Math::BigInt; # blah }

For those who might wonder why 2038.....

my $zero_hour = 2**31 -1; print "Zero hour is $zero_hour\n"; print scalar gmtime($zero_hour), "\n"; print gmtime($zero_hour+1) ? "OK" . scalar gmtime($zero_hour+1) : 'Oh +dear!';

cheers

tachyon

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


Comment on Re: 2038 bug
Select or Download Code
Re: Re: 2038 bug
by pg (Canon) on Apr 11, 2003 at 06:11 UTC
    (After I read tachyon's post again, I thought I should add this comment. i should not second guess his thought too much, and simplify his thought. Any way, I still leave this post here, as some sort of helper to his post.)

    The $begin - $end approach would not work, assume that we get both from a function like time().

    The problem is that, for time(), after it steps over the biggest positive integer, it would go directly to the smallest negative integer, i.e. the negative integer with the biggest absolute value.

    For example, if $begin is 2038-01-18-20:14:06, and $end is 2038-01-18-20:14:07, although there is only 1 second difference, by calling time(), and do $begin - $end, you will get:

    2 ** 31 - 1 - (- 2 ** 31) = 2 ** 32 - 1

      Of course it will work. I said abstract *all time manipulation* into a module. This obviously includes getting the current time from time(). The abstraction is the main thing as it lumps all the problems in one festering little bucket.

      cheers

      tachyon

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

Re: 2038 bug
by Abigail-II (Bishop) on Apr 11, 2003 at 07:26 UTC
    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

      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

      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 grantm (Parson) on Apr 11, 2003 at 08:48 UTC
    But realistically Y2038 is only an issue if time_t is still a 4 byte int in 2038.

    I'm not trying to be a panic monger (lord knows the Y2K 'bug' brought enough of them out of the woodwork!) but the problem is real now. There are plenty of reasons you might want to do a date calculation that went beyond 2038, for example printing a table of predicted values by year for a retirement investment policy, or calculating a mortgage amortisation table, or working out what day of the week to schedule your retirement party :-).

    Don't get me wrong, I'm not suggesting these things are impossible or even hard to do. I'm merely saying that the standard tools like time(), localtime() and Time::Local() will let you down. Dave Rolsky's recent article on Perl.com provides some answers.

      There are plenty of reasons you might want to do a date calculation that went beyond 2038, for example printing a table of predicted values by year for a retirement investment policy, or calculating a mortgage amortisation table, or working out what day of the week to schedule your retirement party.
      Sure, but those are dates. One doesn't calculate a mortgage amortisation table with a precision of a second, nor are parties planned to start at a specific second.

      Abigail

        Sure, but those are dates.

        Agreed. But Perl doesn't provide standard tools for dealing with dates, only date/times.

        One doesn't calculate a mortgage amortisation table with a precision of a second, nor are parties planned to start at a specific second.

        You've never met my German ex-fiance, have you?

        --
        tbone1
        Ain't enough 'O's in 'stoopid' to describe that guy.
        - Dave "the King" Wilson

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (7)
As of 2014-08-27 10:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (237 votes), past polls