The Year 2038 Problem

  • Thread starter Generic Usenet Account
  • Start date
J

Jeff Schwab

M

myren, lord

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
 
K

Keith Thompson

Stephen Sprunk said:
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.
 
M

Mabden

rossum said:

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

Mabden

Jeff Schwab said:
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.
 
M

Mabden

Corey Murtagh said:
AngleWyrm wrote:



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.


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!
 
R

Richard Bos

Alan Balmer said:
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
 
R

Richard Bos

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
 
V

Villy Kruse

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
 
R

Richard Bos

Corey Murtagh said:
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.

The two previous times I heard predictions on that, the dates were 1980
and 2000. So I'm not scared. I see much better reasons for finding
alternative sources of energy; Shell, Exxon, and the oil-guzzling USA
getting a bit nervous don't matter much to me.
15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>

I won't. I'll never be paying US$20 or US$ anything for anything.

Richard
 
G

Gerry Quinn

< snip >

Idiot!! It wasn't "vastly overblown" at all. The fact is,
we did a damn good job fixing it.

In countries where little or no effort was put into preventing it, no
significant problems occurred either.

"Only the vigilance of our firefighters has prevented this 2000-year old
forest from burning to the ground dozens of times over the last decade!"

- Gerry Quinn
 
R

Richard Bos

Alan Balmer said:
What was overblown was Joona's rhetoric, which was why I ignored it.

Joona's rhetoric was mild compared with the hullabaloo which occured in
the newspapers and on TV. Those _did_ present scenarios where everything
from automobiles to coffee makers stopped working - and worse, would
suddenly go berserk. Remember the "all Russian nuclear missiles are
going to go kabloom because they detect a wrong date" scare? Well, I do.

Richard
 
R

Richard Bos

Villy Kruse said:
I'm sure these stories didn't come from the professionals who knew
what they were talking about.

Of course. It wasn't the programmers creating the scare, it was
journalists looking for a story, politicians looking for a vote, and
conmen looking for a fleece. Which is _exactly_ why it was so overblown.

Richard
 
M

Mabden

Bob Day said:
< snip >

Idiot!! It wasn't "vastly overblown" at all. The fact is,
we did a damn good job fixing it.

Indeed, the problem was worked on for over a year and a half at my
workplace. I personally spent many a Saturday and late night for a full
year, with no extra money - ah, salary. Our system had a 2000 and a 20XX
problem (I forget the exact year - maybe the 2038 Unix year) and we spent
many man-hours fixing the problems so that all the sales people would get
their commissions on time, and not have them sent to their grandfathers!
 
M

Mabden

corrlens said:
Hoping we haven't contacted any kind of higher intelligence Humans from
other planet and they want us to modify our date to theirs.

Especially if they happen to be trans-dimensional beings with Multiverse
time / space co-ordinate expectations that require 2048 quad-bit timeline
calculations.

But perhaps we could just send a few Christians over and get them all to
convert to Jesus Time (r).
 
R

Robert W. McAdams

T.M. Sommers said:
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.

Actually, the next big date problem is the Y2100 problem (at least for
those who aren't still concerned about Y2K, which is still 44 years
away). Many programs still assume that any year that's evenly
divisible by 4 is a leap year.


Bob McAdams
Fambright
 
R

Richard Bos

Actually, the next big date problem is the Y2100 problem (at least for
those who aren't still concerned about Y2K, which is still 44 years
away). Many programs still assume that any year that's evenly
divisible by 4 is a leap year.

That's a small date problem, easily corrected. All it takes is an
amendment of a tiny expression to a still not complicated expression.
No changes to any interface are needed, so this is very straightforward
to put into effect.

Richard
 
Q

q

I do not think that t was ever equal to zero,
t only approches zero.
rossum said:
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. The problem is that we don't know what the time is now.
< mode = whatever_passes_for_normal >

rossum
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,763
Messages
2,569,563
Members
45,039
Latest member
CasimiraVa

Latest Threads

Top