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]

Re: The Year 2038 Problem


"Generic Usenet Account" <usenet@sta.sam sung.com> wrote in message
news:90e5135.04 05270826.64cae8 39@posting.goog le.com...
< snip >[color=blue]
> Although the Y2K scare turned out to be vastly overblown,[/color]
< 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]

Re: The Year 2038 Problem

Bob Day <xxxxxxx@yyyyyy y.com> scribbled the following
on comp.lang.c:[color=blue]
> "Generic Usenet Account" <usenet@sta.sam sung.com> wrote in message
> news:90e5135.04 05270826.64cae8 39@posting.goog le.com...
> < snip >[color=green]
>> Although the Y2K scare turned out to be vastly overblown,[/color]
> < snip >[/color]
[color=blue]
> Idiot!! It wasn't "vastly overblown" at all. The fact is,
> we did a damn good job fixing it.[/color]

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 (palaste@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…)]

Re: The Year 2038 Problem

Generic Usenet Account wrote:
[color=blue]
> 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[/color]

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]

Re: The Year 2038 Problem

In <90e5135.040527 0826.64cae839@p osting.google.c om> usenet@sta.sams ung.com (Generic Usenet Account) writes:
[color=blue]
>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.[/color]

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: Dan.Pop@ifh.de

[Guillaume]

Re: The Year 2038 Problem

> In 2038 all OS (Unix included) will have 64 bits[color=blue]
> to hold a Date value and with 64 bits the rollover
> will happen 292 billion years after 1/1/1970.[/color]

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]

Re: The Year 2038 Problem

On 27 May 2004 17:03:29 GMT, Joona I Palaste <palaste@cc.hel sinki.fi>
wrote:
[color=blue]
>Bob Day <xxxxxxx@yyyyyy y.com> scribbled the following
>on comp.lang.c:[color=green]
>> "Generic Usenet Account" <usenet@sta.sam sung.com> wrote in message
>> news:90e5135.04 05270826.64cae8 39@posting.goog le.com...
>> < snip >[color=darkred]
>>> Although the Y2K scare turned out to be vastly overblown,[/color]
>> < snip >[/color]
>[color=green]
>> Idiot!! It wasn't "vastly overblown" at all. The fact is,
>> we did a damn good job fixing it.[/color]
>
>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?[/color]

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
removebalmercon sultingthis@att .net

[corrlens]

Re: The Year 2038 Problem


"Guillaume" <grsNOSPAM@NO-SPAMmail.com> wrote in message
news:40b630cd$0 $315$7a628cd7@n ews.club-internet.fr...[color=blue][color=green]
> > 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.[/color]
>
> 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.[/color]

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]

Re: The Year 2038 Problem

Dan Pop <Dan.Pop@cern.c h> wrote:
[color=blue]
> 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):
>[/color]
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]

Re: [OT] The Year 2038 Problem

"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:c957pb$5mq $2@sunnews.cern .ch...[color=blue]
> In <90e5135.040527 0826.64cae839@p osting.google.c om> usenet@sta.sams ung.com[/color]
(Generic >[color=blue]
> So, what's the next massive problem we have to worry about, now that we
> have just solved this one?[/color]

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

-Mike

[q@q.com]

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:
[color=blue]
> 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
>[/color]

[Peter Ammon]

Re: The Year 2038 Problem

Otto Wyss wrote:
[color=blue]
> Dan Pop <Dan.Pop@cern.c h> wrote:
>
>[color=green]
>>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):
>>[/color]
>
> 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[/color]

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

[Stephen Sprunk]

Re: The Year 2038 Problem

"Generic Usenet Account" <usenet@sta.sam sung.com> wrote in message
news:90e5135.04 05270826.64cae8 39@posting.goog le.com...[color=blue]
> 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.[/color]

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).
[color=blue]
> 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.[/color]

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]

Re: The Year 2038 Problem

"Otto Wyss" <otto.wyss@orpa tec.ch> wrote in message
news:1gegpbt.ot 7t0q1p5gqogN%ot to.wyss@orpatec .ch...[color=blue]
> Dan Pop <Dan.Pop@cern.c h> wrote:
>[color=green]
> > 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):
> >[/color]
> The time_t might have 64-bit but are you sure that every occurence where
> the time is copied or used is as well?[/color]

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

[Emmanuel Delahaye]

Re: The Year 2038 Problem

In 'comp.lang.c', Alan Balmer <albalmer@att.n et> wrote:
[color=blue][color=green]
>>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?[/color]
>
> 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.[/color]

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/