The Year 2038 Problem

[Generic Usenet Account]

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

[Bob Day]

"Generic Usenet Account" <us****@sta.sam sung.com> wrote in message
news:90******** *************** **@posting.goog le.com...
< 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

[Joona I Palaste]

Bob Day <xx*****@yyyyyy y.com> scribbled the following
on comp.lang.c:

"Generic Usenet Account" <us****@sta.sam sung.com> wrote in message
news:90******** *************** **@posting.goog le.com...
< 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 (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III

[Dario (drinking coffee in the office…)]

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

[Dan Pop]

In <90************ *************@p osting.google.c om> us****@sta.sams ung.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 <time.h>
#include <stdio.h>
#include <limits.h>

int main()
{
printf("%d\n", (int)sizeof(tim e_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: Da*****@ifh.de

[Guillaume]

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

[Alan Balmer]

On 27 May 2004 17:03:29 GMT, Joona I Palaste <pa*****@cc.hel sinki.fi>
wrote:

Bob Day <xx*****@yyyyyy y.com> scribbled the following
on comp.lang.c:

"Generic Usenet Account" <us****@sta.sam sung.com> wrote in message
news:90******** *************** **@posting.goog le.com...
< 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
re************* ***********@att .net

[corrlens]

"Guillaume" <gr*******@NO-SPAMmail.com> wrote in message
news:40******** *************@n ews.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.

[Otto Wyss]

Dan Pop <Da*****@cern.c h> 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.sour ceforge.net/"

[Mike Wahler]

"Dan Pop" <Da*****@cern.c h> wrote in message
news:c9******** **@sunnews.cern .ch...

In <90************ *************@p osting.google.c om> us****@sta.sams ung.com (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