The Year 2038 Problem

[Generic Usenet Account]

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/[email protected]]. 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]

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

 

[Guest]

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/[email protected]]. 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

 

[Joona I Palaste]

Bob Day <[email protected]> scribbled the following

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

 

[Dan Pop]

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

 

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

Bob Day <[email protected]> scribbled the following



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.

 

[corrlens]

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]

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

 

[Mike Wahler]

In <[email protected]> (e-mail address removed) (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

 

[q]

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.

 

[Peter Ammon]

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?

 

[Stephen Sprunk]

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]

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

 

[Emmanuel Delahaye]

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

 

[Thomas Matthews]

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/[email protected]]. 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

 

[Gordon Burditt]

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

 

[T.M. Sommers]

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.

 

[Tobin Fricke]

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

 

[Guillaume]

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