The Year 2038 Problem - Unix

This is a discussion on The Year 2038 Problem - Unix ; "corrlens" wrote in message news:CKqtc.12838$Tn6.3624@newsread1.news.pas.earth link.net... > > "Guillaume" wrote in message > news:40b630cd$0$315$7a628cd7@news.club-internet.fr... > > > In 2038 all OS (Unix included) will have 64 bits > > > to hold a Date value and with 64 bits the ...

+ Reply to Thread
Page 3 of 10 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 184

Thread: The Year 2038 Problem

  1. Re: The Year 2038 Problem

    "corrlens" wrote in message
    news:CKqtc.12838$Tn6.3624@newsread1.news.pas.earth link.net...
    >
    > "Guillaume" wrote in message
    > news:40b630cd$0$315$7a628cd7@news.club-internet.fr...
    > > > 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.

    >
    > Hoping we haven't contacted any kind of higher intelligence Humans from
    > other planet and they want us to modify our date to theirs.


    Especially if they happen to be trans-dimensional beings with Multiverse
    time / space co-ordinate expectations that require 2048 quad-bit timeline
    calculations.

    But perhaps we could just send a few Christians over and get them all to
    convert to Jesus Time (r).

    --
    Mabden



  2. Re: The Year 2038 Problem

    "T.M. Sommers" wrote in message news:<0qKdnQpLjrhHwyvdUSdV9g@telcove.net>...
    > 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.


    Actually, the next big date problem is the Y2100 problem (at least for
    those who aren't still concerned about Y2K, which is still 44 years
    away). Many programs still assume that any year that's evenly
    divisible by 4 is a leap year.


    Bob McAdams
    Fambright

  3. Re: The Year 2038 Problem

    rwm@fambright.com (Robert W. McAdams) wrote:

    > Actually, the next big date problem is the Y2100 problem (at least for
    > those who aren't still concerned about Y2K, which is still 44 years
    > away). Many programs still assume that any year that's evenly
    > divisible by 4 is a leap year.


    That's a small date problem, easily corrected. All it takes is an
    amendment of a tiny expression to a still not complicated expression.
    No changes to any interface are needed, so this is very straightforward
    to put into effect.

    Richard

  4. Re: The Year 2038 Problem

    I do not think that t was ever equal to zero,
    t only approches zero.
    rossum wrote:

    > 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. The problem is that we don't know what the time is now.
    > < mode = whatever_passes_for_normal >
    >
    > rossum
    >
    > --
    >
    > The Ultimate Truth is that there is no Ultimate Truth
    >



  5. Re: The Year 2038 Problem

    Not only must the year be divisible by 4, if it is a century
    year it must be divisible by 400.

    Robert W. McAdams wrote:

    > "T.M. Sommers" wrote in message news:<0qKdnQpLjrhHwyvdUSdV9g@telcove.net>...
    >
    >>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.
    >>

    >
    > Actually, the next big date problem is the Y2100 problem (at least for
    > those who aren't still concerned about Y2K, which is still 44 years
    > away). Many programs still assume that any year that's evenly
    > divisible by 4 is a leap year.
    >
    >
    > Bob McAdams
    > Fambright
    >



  6. Re: The Year 2038 Problem

    "Gerry Quinn" wrote in message
    news:MPG.1b20ff0fcc0166cf989681@news.indigo.ie...
    > 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


    Pull your head out of the sand for a moment, and take
    a look at: http://www.grantjeffrey.com/article/y2kretro.htm

    -- Bob Day



  7. Re: The Year 2038 Problem

    In Ben Measures writes:

    >Otto Wyss wrote:
    >> Dan Pop wrote:
    >>>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):

    >>
    >> The time_t might have 64-bit but are you sure that every occurence where
    >> the time is copied or used is as well?

    >
    >By 2038 opensourced software will be abundant and everyone will laugh at
    >those still using proprietry software ;->


    Guess what? Even proprietary software is maintained.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email: Dan.Pop@ifh.de

  8. Re: The Year 2038 Problem

    In gordonb.xoh7d@burditt.org (Gordon Burditt) writes:

    >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.


    Does it matter?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email: Dan.Pop@ifh.de

  9. Re: The Year 2038 Problem

    In "myren, lord" writes:

    >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.


    Yeah, but that would be a 64-bit x 4 vector processor ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email: Dan.Pop@ifh.de

  10. Re: The Year 2038 Problem

    In Gerry Quinn writes:

    >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.


    A country generating no significant software products has nothing to fix.
    It's as simple as that.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email: Dan.Pop@ifh.de

  11. Re: The Year 2038 Problem

    "Corey Murtagh" wrote in message
    news:1085722200.99553@radsrv1.tranzpeer.net...
    > AngleWyrm wrote:
    > > 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 assume that $20 is after inflation, which means it'll be on par (in
    constant dollars) with what we pay for petrol or ethanol today. Hardly a
    problem, though I'd expect us all to be running on hydrogen by then; ethanol
    is a transition fuel.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin


  12. Re: The Year 2038 Problem

    On 27 May 2004 21:27:14 GMT, gordonb.xoh7d@burditt.org (Gordon Burditt)
    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.


    That's ok, we probably know it to at least the same relative accuracy as
    January 1, 1970 "accurately" mirrors the beginning of the Unix era.
    -leor

    >
    >
    > Gordon L. Burditt


    --
    Leor Zolman --- BD Software --- www.bdsoft.com
    On-Site Training in C/C++, Java, Perl and Unix
    C++ users: download BD Software's free STL Error Message Decryptor at:
    www.bdsoft.com/tools/stlfilt.html

  13. Re: The Year 2038 Problem

    In article ,
    xxxxxxx@yyyyyyy.com says...
    > "Gerry Quinn" wrote in message


    > > > > 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.

    >
    > Pull your head out of the sand for a moment, and take
    > a look at: http://www.grantjeffrey.com/article/y2kretro.htm


    LOL! That article was written a mere ten days into the year 2000 by tha
    author of "The Millenial Meltdown", and already he was running for
    cover. He should have waited a few days, some of his his followers
    might not have been down from the hills in time to read it.

    He had no significant examples of serious failures to report, so he
    started pushing that good old line "If it wasn't serious why did we
    spend so much?". Nearly all the article is just "Everybody else said it
    was serious too".

    He asks:
    "Those who naively suggest that Y2K was all hype should ask themselves
    why banks (who are not generally known to throw their money away) would
    spend literally hundreds of millions of dollars and hundreds of
    thousands of man hours to fix the problem..."

    You know, banks *aren't* known for throwing their money away - they've
    got plenty of yours and mine for that! Barings, for example, or AIB.

    There was a Feb 29 bug in 2000 that wasn't hyped at all, and little
    enough went wrong that day either.

    Truth is the Millenium Bug Disaster was a '60s science fiction scenario,
    based on the assumption that all the operations that keep the industrial
    world turning are done by technicians blindly obeying the orders on
    punched cards that some big old computer spits out. The real world is
    considerably more fault tolerant.

    - Gerry Quinn







  14. Re: The Year 2038 Problem

    Stephen Sprunk wrote:
    > "Corey Murtagh" wrote in message
    >

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

    >
    > I assume that $20 is after inflation, which means it'll be on par
    > (in constant dollars) with what we pay for petrol or ethanol
    > today. Hardly a problem, though I'd expect us all to be running
    > on hydrogen by then; ethanol is a transition fuel.


    And where does the power to extract that hydrogen come from? In
    case you hadn't noticed it does not tend to occur in free form in
    nature. However, it can serve as an intermediary between real
    renewable sources and portable machinery.

    --
    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



  15. Re: The Year 2038 Problem

    Stephen Sprunk wrote:

    > "Otto Wyss" wrote in message
    > news:1gegpbt.ot7t0q1p5gqogN%otto.wyss@orpatec.ch.. .
    > > The time_t might have 64-bit but are you sure that every occurence where
    > > the time is copied or used is as well?

    >
    > If someone copies a time_t into a variable of any other type, they may be
    > invoking undefined behavior, which means it's not the Standard's problem,
    > it's the coder's.
    >
    > time_t exists for a reason, just like size_t. Use them.
    >

    I don't hope time_t isn't as often converted to int as size_t is. Well I
    guess it won't be that big problem, I just wanted to point out that you
    never should assume what other coders think.

    O. Wyss

    --
    See a huge pile of work at "http://wyodesktop.sourceforge.net/"

  16. Re: The Year 2038 Problem

    Ben Measures wrote:

    > Otto Wyss wrote:
    > > The time_t might have 64-bit but are you sure that every occurence where
    > > the time is copied or used is as well?

    >
    > By 2038 opensourced software will be abundant and everyone will laugh at
    > those still using proprietry software ;->


    Whow perfect! I'll see that my OpenSource projects are finished be then.

    O. Wyss

    --
    See a huge pile of work at "http://wyodesktop.sourceforge.net/"

  17. Re: The Year 2038 Problem

    On 2004-05-28, Stephen Sprunk wrote:
    > "Corey Murtagh" wrote in message
    > news:1085722200.99553@radsrv1.tranzpeer.net...
    >> AngleWyrm wrote:
    >> > My solution is that I plan to be dead around 2040 or so.


    Hm I might not make that. Fun prospect!


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

    >
    > I assume that $20 is after inflation, which means it'll be on par (in
    > constant dollars) with what we pay for petrol or ethanol today. Hardly a
    > problem, though I'd expect us all to be running on hydrogen by then; ethanol
    > is a transition fuel.


    The fun thing of course is that alcohols are about the simplest things
    to make, and dead cheap too. The only thing that make them so darn
    expensive is the various governements wanting a piece of the action, in
    the interest of letting people have less fun for their dollar.

    Fact is, oil is not as cheap as it seems, as it has rather high cleanup
    costs associated with it. Same with nuclear fuels, but oil doesn't have
    quite such spectacular faillure modes. Altough I have to admit that
    fuel/air bombs are kinda neat. And oily birds make for nice television
    and cause traffic jams with people driving to a different, clean beach.

    Same with our silicon based computing stuffs. They and the facilities
    needed to produce them are not very environment friendly, and the
    pittance some of us now have to pay as advance clean-up costs will not
    be enough to fix the problems the obsoleted debris will create later on.

    Anyway. Whatever we do, we'll pay for it sooner or later. If sufficiently
    late we'll just be cursed by our ancestors. Which would you prefer?


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .

  18. Re: The Year 2038 Problem

    "Otto Wyss" wrote in message
    news:1geihnf.6q45la7adlz4N%otto.wyss@orpatec.ch...
    > Stephen Sprunk wrote:
    >
    > > "Otto Wyss" wrote in message
    > > news:1gegpbt.ot7t0q1p5gqogN%otto.wyss@orpatec.ch.. .
    > > > The time_t might have 64-bit but are you sure that every occurence

    where
    > > > the time is copied or used is as well?

    > >
    > > If someone copies a time_t into a variable of any other type, they may

    be
    > > invoking undefined behavior, which means it's not the Standard's

    problem,
    > > it's the coder's.
    > >
    > > time_t exists for a reason, just like size_t. Use them.
    > >

    > I don't hope time_t isn't as often converted to int as size_t is. Well I
    > guess it won't be that big problem, I just wanted to point out that you
    > never should assume what other coders think.


    Neither time_t nor size_t is ever converted to int in code I write or
    maintain; I can't speak to what others do...

    With the growing adoption of 64-bit desktops we already see bugs where
    people improperly convert size_t to int, at least on platforms where int
    isn't also 64-bit (i.e. AMD64). We'll find out how many people don't use
    time_t correctly in 2038

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin


  19. Re: The Year 2038 Problem

    "CBFalconer" wrote in message
    news:40B751E8.17B69272@yahoo.com...
    > Stephen Sprunk wrote:
    > > I assume that $20 is after inflation, which means it'll be on par
    > > (in constant dollars) with what we pay for petrol or ethanol
    > > today. Hardly a problem, though I'd expect us all to be running
    > > on hydrogen by then; ethanol is a transition fuel.

    >
    > And where does the power to extract that hydrogen come from? In
    > case you hadn't noticed it does not tend to occur in free form in
    > nature. However, it can serve as an intermediary between real
    > renewable sources and portable machinery.


    Hydrogen isn't the original source; however, it is a clean, portable way to
    store and transport energy generated by some other means. Depending on the
    original source, the entire system may or may not be clean, and there's
    varying values of "clean" as well.

    Ethanol is mainly interesting because it has almost the same energy density
    as petrol, has about the same price, runs in the same engines without
    modification (though the fuel system needs anti-corrosion protection), uses
    the same transport and fueling infrastructure, and can be produced nearly
    anywhere in the world. While ethanol is far cleaner than petrol, it's
    nowhere near as clean as hydrogen even if you consider waste generated in
    producing the latter.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Aaron Sorkin


  20. Re: The Year 2038 Problem

    I am not sure hyow hydrogen would be ditributed,
    either to the resellers (filling stations)
    or regionally (to terminals).
    Gasoline is distributed to terminals via pipelines.
    MTBE is also distributed via pipelines. But MTBE
    pollutes ground water.
    Ethanol is shipped via trucks, no pipelines.

    Any thoughts on hydrogen distribution?

    Stephen Sprunk wrote:

    > "CBFalconer" wrote in message
    > news:40B751E8.17B69272@yahoo.com...
    >
    >>Stephen Sprunk wrote:
    >>
    >>>I assume that $20 is after inflation, which means it'll be on par
    >>>(in constant dollars) with what we pay for petrol or ethanol
    >>>today. Hardly a problem, though I'd expect us all to be running
    >>>on hydrogen by then; ethanol is a transition fuel.
    >>>

    >>And where does the power to extract that hydrogen come from? In
    >>case you hadn't noticed it does not tend to occur in free form in
    >>nature. However, it can serve as an intermediary between real
    >>renewable sources and portable machinery.
    >>

    >
    > Hydrogen isn't the original source; however, it is a clean, portable way to
    > store and transport energy generated by some other means. Depending on the
    > original source, the entire system may or may not be clean, and there's
    > varying values of "clean" as well.
    >
    > Ethanol is mainly interesting because it has almost the same energy density
    > as petrol, has about the same price, runs in the same engines without
    > modification (though the fuel system needs anti-corrosion protection), uses
    > the same transport and fueling infrastructure, and can be produced nearly
    > anywhere in the world. While ethanol is far cleaner than petrol, it's
    > nowhere near as clean as hydrogen even if you consider waste generated in
    > producing the latter.
    >
    > S
    >
    >



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