The Year 2038 Problem

Discussion in 'C Programming' started by Generic Usenet Account, May 27, 2004.

  1. As per Google's Usenet archives
    [http://groups.google.com/googlegroups/archive_announce_20.html], the
    first discussion of the Y2K problem on the Usenet was on January 18
    1985 [http://groups.google.com/groups?threadm=]. 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
    Generic Usenet Account, May 27, 2004
    #1
    1. Advertising

  2. Generic Usenet Account

    Bob Day Guest

    "Generic Usenet Account" <> wrote in message
    news:...
    < 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
    Bob Day, May 27, 2004
    #2
    1. Advertising

  3. Generic Usenet Account wrote:

    > As per Google's Usenet archives
    > [http://groups.google.com/googlegroups/archive_announce_20.html], the
    > first discussion of the Y2K problem on the Usenet was on January 18
    > 1985 [http://groups.google.com/groups?threadm=]. 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
    =?UTF-8?B?IkRhcmlvIChkcmlua2luZyBjb++sgGVlIGluIHRo, May 27, 2004
    #3
  4. Bob Day <> scribbled the following
    on comp.lang.c:
    > "Generic Usenet Account" <> wrote in message
    > news:...
    > < 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.


    Oh yeah? How about all those stories about everything from your coffee
    maker to your car engine's sparkplugs stopping working on the exact
    second the year 1999 changes into the year 2000? If that's not "vastly
    overblown", what is? Dogs turning into cats and vice versa?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "C++ looks like line noise."
    - Fred L. Baube III
    Joona I Palaste, May 27, 2004
    #4
  5. Generic Usenet Account

    Dan Pop Guest

    In <> (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 <time.h>
    #include <stdio.h>
    #include <limits.h>

    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, May 27, 2004
    #5
  6. Generic Usenet Account

    Guillaume Guest

    > 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.
    Guillaume, May 27, 2004
    #6
  7. Generic Usenet Account

    Alan Balmer Guest

    On 27 May 2004 17:03:29 GMT, Joona I Palaste <>
    wrote:

    >Bob Day <> scribbled the following
    >on comp.lang.c:
    >> "Generic Usenet Account" <> wrote in message
    >> news:...
    >> < 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.

    >
    >Oh yeah? How about all those stories about everything from your coffee
    >maker to your car engine's sparkplugs stopping working on the exact
    >second the year 1999 changes into the year 2000? If that's not "vastly
    >overblown", what is? Dogs turning into cats and vice versa?


    The only reason it didn't happen was because we fixed it.

    I suppose the world would have appreciated it more if we'd let
    everything go to hell and then became heroes by fixing it afterward.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, May 27, 2004
    #7
  8. Generic Usenet Account

    corrlens Guest

    "Guillaume" <> wrote in message
    news:40b630cd$0$315$-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.
    corrlens, May 27, 2004
    #8
  9. Generic Usenet Account

    Otto Wyss Guest

    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/"
    Otto Wyss, May 27, 2004
    #9
  10. Generic Usenet Account

    Mike Wahler Guest

    Re: [OT] The Year 2038 Problem

    "Dan Pop" <> wrote in message
    news:c957pb$5mq$...
    > In <>

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


    Creating sufficient storage for archival of moronic Usenet posts. :)

    -Mike
    Mike Wahler, May 27, 2004
    #10
  11. Generic Usenet Account

    Guest

    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/googlegroups/archive_announce_20.html], the
    > first discussion of the Y2K problem on the Usenet was on January 18
    > 1985 [http://groups.google.com/groups?threadm=]. 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
    >
    , May 27, 2004
    #11
  12. Generic Usenet Account

    Peter Ammon Guest

    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?
    Peter Ammon, May 27, 2004
    #12
  13. "Generic Usenet Account" <> wrote in message
    news:...
    > 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
    Stephen Sprunk, May 27, 2004
    #13
  14. "Otto Wyss" <> wrote in message
    news:1gegpbt.ot7t0q1p5gqogN%...
    > 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
    Stephen Sprunk, May 27, 2004
    #14
  15. In 'comp.lang.c', Alan Balmer <> wrote:

    >>Oh yeah? How about all those stories about everything from your coffee
    >>maker to your car engine's sparkplugs stopping working on the exact
    >>second the year 1999 changes into the year 2000? If that's not "vastly
    >>overblown", what is? Dogs turning into cats and vice versa?

    >
    > The only reason it didn't happen was because we fixed it.
    >
    > I suppose the world would have appreciated it more if we'd let
    > everything go to hell and then became heroes by fixing it afterward.


    I believe you. I don't understand why people are so 'hot' about this topic.
    Maybe, I just can make the difference between what the TV says and the real
    world...

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
    Emmanuel Delahaye, May 27, 2004
    #15
  16. Generic Usenet Account wrote:
    > As per Google's Usenet archives
    > [http://groups.google.com/googlegroups/archive_announce_20.html], the
    > first discussion of the Y2K problem on the Usenet was on January 18
    > 1985 [http://groups.google.com/groups?threadm=]. 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
    Thomas Matthews, May 27, 2004
    #16
  17. >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
    Gordon Burditt, May 27, 2004
    #17
  18. Generic Usenet Account

    T.M. Sommers Guest

    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.
    T.M. Sommers, May 27, 2004
    #18
  19. Generic Usenet Account

    Tobin Fricke Guest

    On Thu, 27 May 2004, Alan Balmer wrote:

    >> Oh yeah? How about all those stories about everything from your coffee
    >> maker to your car engine's sparkplugs stopping working on the exact
    >> second the year 1999 changes into the year 2000? If that's not "vastly
    >> overblown", what is? Dogs turning into cats and vice versa?

    >
    > The only reason it didn't happen was because we fixed it.


    I don't recall you getting anywhere near my coffee machine or volkswagen.

    Vastly overblown it was.

    --tobin
    Tobin Fricke, May 27, 2004
    #19
  20. Generic Usenet Account

    Guillaume Guest

    > 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...
    Guillaume, May 27, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Otuatail

    Week of year to full Year

    Otuatail, Dec 8, 2003, in forum: HTML
    Replies:
    4
    Views:
    954
    Toby A Inkster
    Dec 8, 2003
  2. Stu

    Normalizing tm structure past 2038

    Stu, Oct 31, 2003, in forum: C Programming
    Replies:
    5
    Views:
    426
    Chris Torek
    Nov 1, 2003
  3. Jean-Baptiste

    class Time doesn't pass year 2038?

    Jean-Baptiste, Jan 5, 2004, in forum: Ruby
    Replies:
    10
    Views:
    211
    Daniel Carrera
    Jan 7, 2004
  4. Veerle
    Replies:
    2
    Views:
    395
    niceguy
    Aug 20, 2003
  5. PerlFAQ Server
    Replies:
    0
    Views:
    376
    PerlFAQ Server
    Jan 6, 2011
Loading...

Share This Page