The Year 2038 Problem - Unix

This is a discussion on The Year 2038 Problem - Unix ; "Guillaume" wrote in message news:40b6621c$0$307$7a628cd7@news.club-internet.fr... > > Hoping we haven't contacted any kind of higher intelligence Humans from > > other planet and they want us to modify our date to theirs. > > Hehe, that might happen indeed. > ...

+ Reply to Thread
Page 2 of 10 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 184

Thread: The Year 2038 Problem

  1. Re: The Year 2038 Problem


    "Guillaume" wrote in message
    news:40b6621c$0$307$7a628cd7@news.club-internet.fr...
    > > Hoping we haven't contacted any kind of higher intelligence Humans from
    > > other planet and they want us to modify our date to theirs.

    >
    > Hehe, that might happen indeed.
    > Who knows, maybe they'll want to store dates with a femtosecond
    > resolution. We wouldn't get very far with 64 bits, then...



    LOL ... And then if we ever colonized the moon and mars and then we have
    real-time databases with planet earth , what's time and date is at the
    moon/mars compared to the earth :-) ..... I'll be dust by that time



  2. Re: The Year 2038 Problem


    >
    > My personal preference would be for a 256-bit number of picoseconds since
    > the creation of the universe. It gives better precision than 1 second.
    > It won't run out during the life of this universe. The only trouble is,
    > we don't know accurately when that was.


    Wouldn't work, time isn't a constant. Doesn't show when your talking about
    seconds, but with picoseconds that will need to be taken into account.
    Number of picosecondes since creation of the universe isn't the same on top
    of mount Everest then at sea level. I wonder how NTP is going to deal with
    that LOL.

    >
    >
    > Gordon L. Burditt




  3. Re: The Year 2038 Problem

    Mario Charest wrote:
    >>My personal preference would be for a 256-bit number of picoseconds since
    >>the creation of the universe. It gives better precision than 1 second.
    >>It won't run out during the life of this universe. The only trouble is,
    >>we don't know accurately when that was.

    >
    >
    > Wouldn't work, time isn't a constant. Doesn't show when your talking about
    > seconds, but with picoseconds that will need to be taken into account.
    > Number of picosecondes since creation of the universe isn't the same on top
    > of mount Everest then at sea level. I wonder how NTP is going to deal with
    > that LOL.
    >
    >
    >>
    >>Gordon L. Burditt




    I hereby nominate Bell Labs as the relative center of time, hence forth
    referred to as the Origin. The time at which any event occurs is not
    the local time, but the perceived time at the Origin "when" the event
    occurred, even if the event was not "then" directly observable from the
    Origin.

  4. Re: The Year 2038 Problem



    Thomas Matthews wrote:

    > Generic Usenet Account wrote:
    >
    >> As per Google's Usenet archives
    >> [http://groups.google.com/googlegroup...ounce_20.html], the
    >> first discussion of the Y2K problem on the Usenet was on January 18
    >> 1985 [http://groups.google.com/groups?thre...0%40reed.UUCP]. That
    >> is a good 15 years before the problem manifested. Even then, it
    >> turned out, we were scrambling for cover when the D-day was
    >> approaching.
    >>
    >> Although the Y2K scare turned out to be vastly overblown, we do have a
    >> massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
    >> 18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
    >> After that, the time on the Unix systems will read as Fri Dec 13
    >> 14:45:52 1901.
    >>
    >> IMHO, if we want to avoid the last minute panic that we witnessed
    >> towards the end of the last millennium (while pursuing the Y2K
    >> problem), we should begin the process of debating the viable solutions
    >> to this problem NOW. It will take a long time for the consensus to be
    >> built, and to come up with a solution that most (if not all) people
    >> find acceptable. We also need considerable time to test out all
    >> possible solutions in the real world, to decide if the solutions
    >> really work as expected. We may also need to develop a suite of
    >> recovery strategies should the problem manifest in some system on that
    >> fateful Monday morning. All this takes time. So, as the late Todd
    >> Beamer would have said: Let's roll.
    >>
    >> Bhat

    >
    >
    > [sarcasm on]
    > I believe that we should all go out and hunt down these old
    > Unix boxes and fix them. After all, this is way more important
    > than getting Windows to stop that Blue Screen of Death during
    > shutdown, holes in the security systems of servers and reduction
    > of spam.



    No, No, No. These old Unix boxes should be replaced with the latest,
    state-of-the-art hardware.
    In 2038 these boxes will be as slow as 4.77Mhz x86 processors
    from 1980's.


    >
    > After all, there are at least 33 more years to develop a
    > good panic. It will probably take that long to find these machines
    > that are in charge of all the critical activities in the world.
    > See, smart people don't use machines that say programs have executed
    > illegal instructions (when it is the operating systems's fault).
    >
    > Nope, stopping those Cell Phone spammers isn't as important because
    > these cell phones are not controlling critical systems (and I know
    > because I've either worked on them or seen them all).
    >
    > So how will I panic, hmm, I don't know, but I've got a while to
    > figure it out. I think I will use my computer that requires
    > rebooting once a day, using appllications that can't communicate
    > with the operating system, even though they are made by the same
    > company. Yep, I search those web sites that will download spyware
    > onto my machine so they can see how I am panicking.
    >
    > Yep, I've just added another item to my worry list. Someday,
    > I'll actually review it. :-)
    >
    > [End of sarcasm]
    >
    >



  5. Re: The Year 2038 Problem

    It took ONE WEEK to verify that ALL systems were Y2K compliant.
    No H1b visas were required!!!


    T.M. Sommers wrote:

    > Dan Pop wrote:
    >
    >>
    >> So, what's the next massive problem we have to worry about, now that we
    >> have just solved this one?

    >
    >
    > The Y10K problem, when all those 4-digit years everyone is so proud of
    > become obsolete. If it took several years to fix just 40 years worth of
    > software for the Y2K problem, just think how long it will take to fix
    > 8000 years worth of software for the Y10K problem. We had better get
    > started right away. There is no time to lose.
    >



  6. Re: The Year 2038 Problem

    "Dan Pop" wrote in message
    news:c957pb$5mq$2@sunnews.cern.ch...
    > In <90e5135.0405270826.64cae839@posting.google.com> usenet@sta.samsung.com

    (Generic Usenet Account) writes:
    >
    >
    > Nope, this won't happen. By then, time_t will be a 64-bit type, as it
    > already is on some 64-bit platforms (e.g. all 64-bit Linux ports):


    > So, what's the next massive problem we have to worry about, now that we
    > have just solved this one?


    The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
    current rate of 80 million/day, it will be completely gone within the lifespans
    of some of the folks walking the earth today.

    My solution is that I plan to be dead around 2040 or so.



  7. Re: The Year 2038 Problem

    wrote in message news:40B64E53.6060104@q.com...
    > No need to go into 'panic mode'.
    > There is time to resolve this issue
    > in a calm, cool and collected manner.
    > Certainly 64 bit processors and/or long long
    > data type will go a long way to resolving the issue.
    > But there will NOT be any need to import
    > thousands of H1b visas to fix this problem.
    > Y2K was definitely blown way out of proportion!
    > This was done by high priced consulting companies
    > trying to justify their worth.


    Yes, no need to panic. What we need here a small team of specialists, gathered
    together in a committee. Over the course of their lives, with the benefit of
    government funding, I'm sure this top-notch group of problem solvers will come
    forth with a resolution to our problem.



  8. Re: The Year 2038 Problem

    Center of time is the United States Naval Observatory.
    http://tycho.usno.navy.mil/history.html
    http://tycho.usno.navy.mil/master.html
    http://tycho.usno.navy.mil/clocks.html

    Jeff Schwab wrote:

    > Mario Charest wrote:
    >
    >>> My personal preference would be for a 256-bit number of picoseconds
    >>> since
    >>> the creation of the universe. It gives better precision than 1 second.
    >>> It won't run out during the life of this universe. The only trouble is,
    >>> we don't know accurately when that was.

    >>
    >>
    >>
    >> Wouldn't work, time isn't a constant. Doesn't show when your talking
    >> about
    >> seconds, but with picoseconds that will need to be taken into account.
    >> Number of picosecondes since creation of the universe isn't the same
    >> on top
    >> of mount Everest then at sea level. I wonder how NTP is going to deal
    >> with
    >> that LOL.
    >>
    >>
    >>>
    >>> Gordon L. Burditt

    >>

    >
    >
    >
    > I hereby nominate Bell Labs as the relative center of time, hence forth
    > referred to as the Origin. The time at which any event occurs is not
    > the local time, but the perceived time at the Origin "when" the event
    > occurred, even if the event was not "then" directly observable from the
    > Origin.



  9. Re: The Year 2038 Problem

    Gordon Burditt wrote:
    >
    >> Although the Y2K scare turned out to be vastly overblown, we do
    >> have a massive problem ahead of us ------ the Year 2038 problem.
    >> On Mon Jan 18 21:14:07 2038, the Unix seconds-since-epoch count
    >> will "roll-over". After that, the time on the Unix systems will
    >> read as Fri Dec 13 14:45:52 1901.

    >
    > That depends on whether the system considers a time_t to be
    > signed or unsigned. Some UNIX systems consider the time range
    > of a traditional 32-bit time_t to be 1970 thru something like
    > 2106, not 1901 thru 2038.


    The obvious cure is to switch to the CP/M standard date format,
    which is a 16 bit unsigned value expressing the count of days
    since 1977-12-31. 0 is 'unknown'. This postpones the problem
    until about 2157 or so.

    Quite a good troll, he didn't need to prod it further.

    --
    fix (vb.): 1. to paper over, obscure, hide from public view; 2.
    to work around, in a way that produces unintended consequences
    that are worse than the original problem. Usage: "Windows ME
    fixes many of the shortcomings of Windows 98 SE". - Hutchison



  10. Re: The Year 2038 Problem


    > Jeff Schwab wrote:
    >
    >> Mario Charest wrote:
    >>
    >>>> My personal preference would be for a 256-bit number of picoseconds
    >>>> since
    >>>> the creation of the universe. It gives better precision than 1 second.
    >>>> It won't run out during the life of this universe. The only trouble
    >>>> is,
    >>>> we don't know accurately when that was.
    >>>
    >>>
    >>>
    >>>
    >>> Wouldn't work, time isn't a constant. Doesn't show when your talking
    >>> about
    >>> seconds, but with picoseconds that will need to be taken into account.
    >>> Number of picosecondes since creation of the universe isn't the same
    >>> on top
    >>> of mount Everest then at sea level. I wonder how NTP is going to
    >>> deal with
    >>> that LOL.
    >>>
    >>>
    >>>>
    >>>> Gordon L. Burditt
    >>>
    >>>

    >>
    >>
    >>
    >> I hereby nominate Bell Labs as the relative center of time, hence
    >> forth referred to as the Origin. The time at which any event occurs
    >> is not the local time, but the perceived time at the Origin "when" the
    >> event occurred, even if the event was not "then" directly observable
    >> from the Origin.

    >
    >


    q@q.com top-posted:
    > Center of time is the United States Naval Observatory.
    > http://tycho.usno.navy.mil/history.html
    > http://tycho.usno.navy.mil/master.html
    > http://tycho.usno.navy.mil/clocks.html


    There are plenty of existing "centers of time," and I might also mention
    Greenwich. I'm suggesting a center not to be used as an actual point of
    physical measurement, but as a conceptual reference point for use in
    software.

  11. Re: The Year 2038 Problem

    AngleWyrm wrote:


    > The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
    > current rate of 80 million/day, it will be completely gone within the lifespans
    > of some of the folks walking the earth today.


    Last time I heard a prediction on that (which wasn't all that recent,
    admittedly), trend analysis on usage vs known (or suspected) supplies
    put the run-out point around 2025.

    So yeah, I think a /lot/ of folks here will see the end.

    > My solution is that I plan to be dead around 2040 or so.


    15 years after the oil runs out and we're all paying US$20/gallon for
    vehicle grade alcohol :>

    --
    Corey Murtagh
    The Electric Monk
    "Quidquid latine dictum sit, altum viditur!"

  12. Re: The Year 2038 Problem

    Guillaume wrote:
    >> In 2038 all OS (Unix included) will have 64 bits
    >> to hold a Date value and with 64 bits the rollover
    >> will happen 292 billion years after 1/1/1970.


    > Which is why we probably won't ever need any more than
    > 64 bits to hold dates.


    > Our galaxy will probably have collapsed by then, and
    > maybe along with the whole universe.


    God forbid I'm not running at least 256 bits by then.

    Myren

  13. Re: The Year 2038 Problem

    "Stephen Sprunk" writes:
    > "Gordon Burditt" wrote in message
    > news:c95mfi$65g@library2.airnews.net...
    > > My personal preference would be for a 256-bit number of picoseconds since
    > > the creation of the universe. It gives better precision than 1 second.
    > > It won't run out during the life of this universe. The only trouble is,
    > > we don't know accurately when that was.

    >
    > You assume a "when" exists; relativity says that's impossible.
    >
    > Relativity aside, there's nothing preventing time_t from being a
    > floating-point number whose zero is at a particular epoch. Epsilon of the
    > chosen type determines the precision of your clock.


    With a floating-point type, the precision of your clock is also
    determined by how far you are from the epoch. I'd rather have a
    consistent precision over the entire representable range than be able
    to measure picoseconds close to the epoch, but have the precision drop
    by a factor of two every now and then.

    --
    Keith Thompson (The_Other_Keith) kst-u@mib.org
    San Diego Supercomputer Center <*>
    We must do something. This is something. Therefore, we must do this.

  14. Re: The Year 2038 Problem

    "rossum" wrote in message
    news:46pcb0tco7vnc54f8e4nsf8f5adj56fftb@4ax.com...
    > On 27 May 2004 21:27:14 GMT, gordonb.xoh7d@burditt.org (Gordon
    > Burditt) wrote:
    >
    > >>[snip]

    > >
    > >My personal preference would be for a 256-bit number of picoseconds since
    > >the creation of the universe. It gives better precision than 1 second.
    > >It won't run out during the life of this universe. The only trouble is,
    > >we don't know accurately when that was.
    > >
    > >
    > > Gordon L. Burditt

    > < mode = nitpick >
    > Not quite accurate. We know precisely when the universe started; at
    > time = 0.


    But only for relatively small values of zero.

    > The problem is that we don't know what the time is now.
    > < mode = whatever_passes_for_normal >


    Thursday, about tea time. Always.

    --
    Mabden



  15. Re: The Year 2038 Problem

    "Jeff Schwab" wrote in message
    news:k-GdnRbmXKugJyvd4p2dnA@comcast.com...
    >
    > I hereby nominate Bell Labs as the relative center of time, hence forth
    > referred to as the Origin.


    I already pay them for "overages" on my cell phone. Please, don't ask me to
    pay them on my LIFE, as well.

    --
    Mabden



  16. Re: The Year 2038 Problem

    "Corey Murtagh" wrote in message
    news:1085722200.99553@radsrv1.tranzpeer.net...
    > AngleWyrm wrote:
    >
    >
    > > The entire planet's 3 thrillion barrels of oil is about 25% gone, and at

    the
    > > current rate of 80 million/day, it will be completely gone within the

    lifespans
    > > of some of the folks walking the earth today.

    >
    > Last time I heard a prediction on that (which wasn't all that recent,
    > admittedly), trend analysis on usage vs known (or suspected) supplies
    > put the run-out point around 2025.
    >
    > So yeah, I think a /lot/ of folks here will see the end.
    >
    > > My solution is that I plan to be dead around 2040 or so.

    >
    > 15 years after the oil runs out and we're all paying US$20/gallon for
    > vehicle grade alcohol :>
    >


    Yeah, there's always methane and grain alcohol - too expensive now, but
    cheap when the oil runs out and costs $200 a barrel.

    Those people will be livid with us, you know! They are going to have a space
    station and off world places to go to. They'll really need rocket fuel and
    have great ways of turning crude oil into fantastic new fuels with great
    efficiency. They'll have cars running on corn (like we could now). But they
    won't have the prime crude oil! They'll be boiling shale to eke out tiny
    amounts of oil!

    They'll look back and curse us for using all the primo stuff on CARS and
    PLANES!!! It'll be, like, "You IDIOTS! You could have just burned Vodka and
    gotten around on Earth! We need the good stuff NOW!!!!"

    HeHe The future sucks!

    --
    Mabden



  17. Re: The Year 2038 Problem

    usenet@sta.samsung.com (Generic Usenet Account) wrote:

    > Although the Y2K scare turned out to be vastly overblown, we do have a
    > massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
    > 18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
    > After that, the time on the Unix systems will read as Fri Dec 13
    > 14:45:52 1901.


    I see a two-step solution, doing one thing and refraining from doing
    another. Step one: start using 64-bit time_t's. Step two: stop storing
    time_t's directly on disk, use standardised (ISO) formats.
    Times and dates presented to your user need not change at all, since
    presenting a user with an undecoded time_t is cruel and unusual
    punishment anyway; therefore, there are none of the socio-behavioural
    problems that surrounded the Y2K problem.

    Richard

  18. Re: The Year 2038 Problem

    Corey Murtagh wrote:

    > AngleWyrm wrote:
    >
    > > The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
    > > current rate of 80 million/day, it will be completely gone within the lifespans
    > > of some of the folks walking the earth today.

    >
    > Last time I heard a prediction on that (which wasn't all that recent,
    > admittedly), trend analysis on usage vs known (or suspected) supplies
    > put the run-out point around 2025.


    The two previous times I heard predictions on that, the dates were 1980
    and 2000. So I'm not scared. I see much better reasons for finding
    alternative sources of energy; Shell, Exxon, and the oil-guzzling USA
    getting a bit nervous don't matter much to me.

    > > My solution is that I plan to be dead around 2040 or so.

    >
    > 15 years after the oil runs out and we're all paying US$20/gallon for
    > vehicle grade alcohol :>


    I won't. I'll never be paying US$20 or US$ anything for anything.

    Richard

  19. Re: The Year 2038 Problem

    In article ,
    xxxxxxx@yyyyyyy.com says...
    > "Generic Usenet Account" wrote in message
    > news:90e5135.0405270826.64cae839@posting.google.co m...
    > < snip >
    > > Although the Y2K scare turned out to be vastly overblown,

    > < snip >
    >
    > Idiot!! It wasn't "vastly overblown" at all. The fact is,
    > we did a damn good job fixing it.


    In countries where little or no effort was put into preventing it, no
    significant problems occurred either.

    "Only the vigilance of our firefighters has prevented this 2000-year old
    forest from burning to the ground dozens of times over the last decade!"

    - Gerry Quinn


  20. Re: The Year 2038 Problem

    "Bob Day" wrote in message
    news:nZotc.24498$rb.9722@nwrdny03.gnilink.net...
    >
    > "Generic Usenet Account" wrote in message
    > news:90e5135.0405270826.64cae839@posting.google.co m...
    > < snip >
    > > Although the Y2K scare turned out to be vastly overblown,

    > < snip >
    >
    > Idiot!! It wasn't "vastly overblown" at all. The fact is,
    > we did a damn good job fixing it.


    Indeed, the problem was worked on for over a year and a half at my
    workplace. I personally spent many a Saturday and late night for a full
    year, with no extra money - ah, salary. Our system had a 2000 and a 20XX
    problem (I forget the exact year - maybe the 2038 Unix year) and we spent
    many man-hours fixing the problems so that all the sales people would get
    their commissions on time, and not have them sent to their grandfathers!

    --
    Mabden



+ Reply to Thread
Page 2 of 10 FirstFirst 1 2 3 4 ... LastLast