The Year 2038 Problem - Unix

This is a discussion on The Year 2038 Problem - Unix ; 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 ...

+ Reply to Thread
Page 1 of 10 1 2 3 ... LastLast
Results 1 to 20 of 184

Thread: The Year 2038 Problem

  1. The Year 2038 Problem

    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

  2. Re: The Year 2038 Problem


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

    -- Bob Day



  3. Re: The Year 2038 Problem

    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


    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.

    - Dario

  4. Re: The Year 2038 Problem

    In <90e5135.0405270826.64cae839@posting.google.com> usenet@sta.samsung.com (Generic Usenet Account) writes:

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


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

    lx64:~/tmp 13> cat test.c
    #include
    #include
    #include

    int main()
    {
    printf("%d\n", (int)sizeof(time_t) * CHAR_BIT);
    return 0;
    }
    lx64:~/tmp 14> gcc test.c
    lx64:~/tmp 15> ./a.out
    64

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

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

  5. Re: The Year 2038 Problem

    On 2004-05-27, Dan Pop 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.

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


    FreeBSD/AMD64 too, I just happen to see last week.

  6. Re: The Year 2038 Problem

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

  7. Re: The Year 2038 Problem


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



  8. Re: The Year 2038 Problem

    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?

    O. Wyss

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

  9. Re: The Year 2038 Problem

    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.

    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
    >



  10. Re: The Year 2038 Problem

    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?
    >
    > O. Wyss


    34 years ago was 1970; how many programs from that era are running on
    modern hardware without having been recompiled?

  11. Re: The Year 2038 Problem

    "Generic Usenet Account" wrote in message
    news:90e5135.0405270826.64cae839@posting.google.co m...
    > 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.


    You mean systems which use a signed 32-bit int for time_t. Modern systems
    use a 64-bit int for time_t, so the problem is moot (unless you're running
    code in 2038 that hasn't been recompiled since the early 1990s).

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


    There already is a solution, consensus for it, and implementations of it.
    The sky is NOT falling.

    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

    "Otto Wyss" wrote in message
    news:1gegpbt.ot7t0q1p5gqogN%otto.wyss@orpatec.ch.. .
    > 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?


    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.

    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


  13. Re: The Year 2038 Problem

    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.

    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]


    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c++-faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c++/faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book


  14. Re: The Year 2038 Problem

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

    There is also no prohibition of using a larger integer for a time_t.
    This isn't an ANSI C problem. It may be a POSIX problem, although
    I'm not sure whether POSIX says anything about time_t's having to
    have exactly 32 bits. (Some systems already use 64 bits, I believe,
    and those processors will become more popular as it gets closer to
    2038, if they're not obsoleted by the 4096-bit processors.)

    Now, this creates problems if you're storing time_t's on disk as, for
    example, file timestamps, but it doesn't rule out converting the filesystem
    including 0-extending or sign-extending the time_t to more bits.

    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

  15. Re: The Year 2038 Problem

    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.


  16. Re: The Year 2038 Problem

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

  17. Re: The Year 2038 Problem

    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

  18. Re: The Year 2038 Problem

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


    Given we want to represent times in the past as well as the future, it would
    be reasonable to fix 'now' (give or take) as midpoint in the range, so why
    not arbitrarily pick

    00:00:00.000 on the morning of January First 0001 as
    1-followed-by-255-zeroes (256-bit unsigned value).

    --
    Roger



  19. Re: The Year 2038 Problem

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

    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

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

    By 2000, OSes could afford four digit years. The problem wasn't new
    software that included enough space. The problem was old files, old
    databases, and old software (some without source code). If you can
    guarentee that changing time_t to 64 bits will automatically convert
    32 bit values in existing files, databases, and object code, then
    you're right, no problem.

    If the conversion is not automatic, then it's Y2K all over again.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    What kind of convenience store do you run here?

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