473,796 Members | 2,654 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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
Nov 14 '05
248 10567
AngleWyrm wrote:

<snip>
The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
current rate of 80 million/day, it will be completely gone within the lifespans
of some of the folks walking the earth today.
Last time I heard a prediction on that (which wasn't all that recent,
admittedly), trend analysis on usage vs known (or suspected) supplies
put the run-out point around 2025.

So yeah, I think a /lot/ of folks here will see the end.
My solution is that I plan to be dead around 2040 or so.


15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>

--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
Nov 14 '05 #41
Guillaume wrote:
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.


God forbid I'm not running at least 256 bits by then. ;)

Myren
Nov 14 '05 #42
"Stephen Sprunk" <st*****@sprunk .org> writes:
"Gordon Burditt" <go***********@ burditt.org> wrote in message
news:c9******** @library2.airne ws.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.


With a floating-point type, the precision of your clock is also
determined by how far you are from the epoch. I'd rather have a
consistent precision over the entire representable range than be able
to measure picoseconds close to the epoch, but have the precision drop
by a factor of two every now and then.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #43

"Joona I Palaste" <pa*****@cc.hel sinki.fi> wrote in message
news:c9******** **@oravannahka. helsinki.fi...
q@q.com <q@q.com> scribbled the following
on comp.lang.c:
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.


What's with the obsession about H1b visas then, eh?


Some folks are insecure, and thus greatly fear
competition. I welcome it.

-Mike
Nov 14 '05 #44
"rossum" <ro******@coldm ail.com> wrote in message
news:46******** *************** *********@4ax.c om...
On 27 May 2004 21:27:14 GMT, go***********@b urditt.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.


But only for relatively small values of zero.
The problem is that we don't know what the time is now.
< mode = whatever_passes _for_normal >


Thursday, about tea time. Always.

--
Mabden
Nov 14 '05 #45
"Jeff Schwab" <je******@comca st.net> wrote in message
news:k-*************** *****@comcast.c om...

I hereby nominate Bell Labs as the relative center of time, hence forth
referred to as the Origin.


I already pay them for "overages" on my cell phone. Please, don't ask me to
pay them on my LIFE, as well.

--
Mabden
Nov 14 '05 #46
"Corey Murtagh" <em***@slingsho t.no.uce> wrote in message
news:10******** ******@radsrv1. tranzpeer.net.. .
AngleWyrm wrote:

<snip>
The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the current rate of 80 million/day, it will be completely gone within the lifespans of some of the folks walking the earth today.


Last time I heard a prediction on that (which wasn't all that recent,
admittedly), trend analysis on usage vs known (or suspected) supplies
put the run-out point around 2025.

So yeah, I think a /lot/ of folks here will see the end.
My solution is that I plan to be dead around 2040 or so.


15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>


Yeah, there's always methane and grain alcohol - too expensive now, but
cheap when the oil runs out and costs $200 a barrel.

Those people will be livid with us, you know! They are going to have a space
station and off world places to go to. They'll really need rocket fuel and
have great ways of turning crude oil into fantastic new fuels with great
efficiency. They'll have cars running on corn (like we could now). But they
won't have the prime crude oil! They'll be boiling shale to eke out tiny
amounts of oil!

They'll look back and curse us for using all the primo stuff on CARS and
PLANES!!! It'll be, like, "You IDIOTS! You could have just burned Vodka and
gotten around on Earth! We need the good stuff NOW!!!!"

HeHe The future sucks!

--
Mabden
Nov 14 '05 #47
Alan Balmer <al******@att.n et> wrote:
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,
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.


No, the reason _those_ did not happen is because coffee makers and spark
plugs don't stop working on 1-1-1900. The reason _normal_ computers
didn't stop working is because we fixed them (and usually well before
the goverment and scare media got their wits around the problem at all),
but the panic in "the press" was about much more than just normal
computers which actually use dates. FFS, people were selling
"Y2K-compatible" printer cables!
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.


Now there I can't help but agree with you.

Richard
Nov 14 '05 #48
us****@sta.sams ung.com (Generic Usenet Account) 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.


I see a two-step solution, doing one thing and refraining from doing
another. Step one: start using 64-bit time_t's. Step two: stop storing
time_t's directly on disk, use standardised (ISO) formats.
Times and dates presented to your user need not change at all, since
presenting a user with an undecoded time_t is cruel and unusual
punishment anyway; therefore, there are none of the socio-behavioural
problems that surrounded the Y2K problem.

Richard
Nov 14 '05 #49
On 28 May 2004 04:15:10 GMT,
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote:


I am quite sure I've heard stories about everything having an
electronic timer stopping working in 2000.


I'm sure these stories didn't come from the professionals who knew
what they were talking about. Besides, the problem is just a small
subset of a bigger issue, namely the maximum number that can be stored
in a given variable. It could for exmple be an old cash register which
didn't allow prices above 10 dollars for example. Or fuel pumps which
got into trouble when the fuel price went above 1.00. Or accounting
programs which gets into trouble when turnover reaches one million,
or 10 million. Or the position argument you give to the fseek()
function, now when files greater than 2Gig is a real posibility.
Villy
Nov 14 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.