473,763 Members | 7,541 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 10505
Michael Wojcik <mw*****@newsgu y.com> coughed up the following:
[Snipped most of the newsgroups, as this troll thread was ridiculously
crossposted.]

In article <MP************ ************@ne ws.indigo.ie>, Gerry Quinn
<ge****@DELETET HISindigo.ie> writes:
"Gerry Quinn" <ge****@DELETET HISindigo.ie> wrote in message

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


There was a Feb 29 bug in 2000 that wasn't hyped at all, and little
enough went wrong that day either.


This is rather impressively arrogant even for you, Gerry.

I personally saw numerous major projects that identified and corrected
Y2K bugs (including Feb 29 2000 bugs, and other variants) in in-use
production code that would have caused major difficulty and expense
for its users, and I wasn't even involved in Micro Focus' Y2K
remediation
business.

Do you have any evidence for either of the claims above?
Truth is the Millenium Bug Disaster was a '60s science fiction
scenario,


The truth is that you're making unsubstantiated claims about a subject
you've demonstrated no actual knowledge of.
based on the assumption that all the operations that keep the
industrial
world turning are done by technicians blindly obeying the orders on
punched cards that some big old computer spits out.


No, the actual assessment of the problem - not the myth reported by
an ignorant news industry - was based on actual examination of actual
running code.
The real world is
considerably more fault tolerant.


The real world runs a great deal of very fragile code. I've seen
quite a bit of it running at customer sites, and again that's just
incidental to my actual job. I rarely look at customer code, but
the bits I do see are not, in fact, particularly tolerant of faults.

A great deal of effort went into fixing real bugs in real code before
the rollover. It was a problem and it was handled. Those who claim
there was no problem are just as misinformed as those who hyped it
beforehand.

Michael, you're right.

As evidenced by /this/ ng in particular, It seems that some people are
prone to over simplified explanations, and are quick to point fingers at
past melodramas as if to say "I knew better." Furthermore some people
seem to only have hind-sight.

The truly interesting thing about y2k is that it wasn't the case that it
was a fear among the masses and that the engineers knew better. It was
the other way around: the masses had little clue UNTIL the hype and the
engineers knew all along.

It was truly amazing that as little failed as it did. You can test each
of the following, fix it for y2k, and verify it independently:

nuclear sub software
NYSE software
FAA control tower software
McDonald's french fry calibration software

....but you /can not/ have the entire world do a dry-run and test all of
those things at *once*.

So much software relies on other software working. We were /right/ to
worry about a cascade effect.

--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #101
Dik T. Winter <Di********@cwi .nl> coughed up the following:
In article <c9*********@ne ws4.newsguy.com > mw*****@newsguy .com writes:
...
> I personally saw numerous major projects that identified and

corrected > Y2K bugs (including Feb 29 2000 bugs, and other
variants) in in-use > production code that would have caused major
difficulty and expense > for its users, and I wasn't even involved
in Micro Focus' Y2K remediation > business.

Might have been. But the way it was hyped, management in many cases
have gone out of their way to ensure that no Y2K problems did exist.
Even when the technically knowledgable said that there would be *no*
major problem. And printing 1-1-2000 as 1-1-100, 1-1-1900 or
1-1-19100,
is *not* a major problem. I know of people that had to ensure that
part of the software was Y2K immune, *even when the software did not
care about the date at all*. Like compilers. "Is gcc Y2K immune?"

The problem was almost never the date itself. It was the possibility
that a chain of causality would ensue, with each domino knocking over an
ever bigger one. Wow, was that a bad metaphor.

ALL software engineers know of the disasters that can infrequently occur
when seemingly innocuous parts of a system fail. In my years I've seen
all kinds of improbable interconnected hoo-haa.

And it was therefore CRITICAL that compilers, the /makers/ of the
software, be fixed.

I was not one of the Y2K hissy fitters----at the time I was one of those
saying "bah, nothing'll happen". But I said so foolishly.

--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #102
AngleWyrm <no************ ***@hotmail.com > coughed up the following:
"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 Usenet Account) writes:


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):

So, what's the next massive problem we have to worry about, now that
we
have just solved this one?


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.

My solution is that I plan to be dead around 2040 or so.

When I was in middle school, mid to late 70's, they told us with
completely /authoritative tones/ that if the world were entirely hollow
and filled with oil that it would be used up before the year 2020.

eeeeeeeeee-Yuh.

--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #103
CBFalconer <cb********@yah oo.com> coughed up the following:
Stephen Sprunk wrote:
"Corey Murtagh" <em***@slingsho t.no.uce> wrote in message
... snip ...

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


I assume that $20 is after inflation, which means it'll be on par
(in constant dollars) with what we pay for petrol or ethanol
today. Hardly a problem, though I'd expect us all to be running
on hydrogen by then; ethanol is a transition fuel.


And where does the power to extract that hydrogen come from?


Nuclear power plants.

In
case you hadn't noticed it does not tend to occur in free form in
nature. However, it can serve as an intermediary between real
renewable sources and portable machinery.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison


--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #104
jpd <re**********@d o.not.spam.it> coughed up the following:
On 2004-05-28, Stephen Sprunk <st*****@sprunk .org> wrote:
"Corey Murtagh" <em***@slingsho t.no.uce> wrote in message
news:10******** ******@radsrv1. tranzpeer.net.. .
AngleWyrm wrote:
My solution is that I plan to be dead around 2040 or so.
Hm I might not make that. Fun prospect!

15 years after the oil runs out and we're all paying US$20/gallon
for vehicle grade alcohol :>
I assume that $20 is after inflation, which means it'll be on par (in
constant dollars) with what we pay for petrol or ethanol today.
Hardly a problem, though I'd expect us all to be running on hydrogen
by then; ethanol is a transition fuel.


The fun thing of course is that alcohols are about the simplest things
to make, and dead cheap too. The only thing that make them so darn
expensive is the various governements wanting a piece of the action,
in
the interest of letting people have less fun for their dollar.

Fact is, oil is not as cheap as it seems, as it has rather high
cleanup
costs associated with it. Same with nuclear fuels, but oil doesn't
have
quite such spectacular faillure modes. Altough I have to admit that
fuel/air bombs are kinda neat. And oily birds make for nice television
and cause traffic jams with people driving to a different, clean
beach.

Same with our silicon based computing stuffs. They and the facilities
needed to produce them are not very environment friendly, and the
pittance some of us now have to pay as advance clean-up costs will not
be enough to fix the problems the obsoleted debris will create later
on.

Anyway. Whatever we do, we'll pay for it sooner or later. If
sufficiently late we'll just be cursed by our ancestors. Which would
you prefer?

I'm thinking they're gonna hate us for one thing for another. If not
for environmental reasons then perhaps social. Heck, we might as well
give'm something to cry about. Let's go melt them polar caps good.
Er......wait a while....


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .


--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #105
Roger Willcocks <rk**@rops.or g> coughed up the following:
"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.


Given we want to represent times in the past as well as the future,
it would be reasonable to fix 'now' (give or take) as midpoint in the
range, so why not arbitrarily pick

00:00:00.000 on the morning of January First 0001 as
1-followed-by-255-zeroes (256-bit unsigned value).

Without doing the math....Does that leave it possible to have years
/before/ the begining of time?


--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #106
<q@q.com> wrote in message news:40******** ******@q.com...

Stephen Sprunk wrote:
Ethanol is mainly interesting because it has almost the same energy density as petrol, has about the same price, runs in the same engines without
modification (though the fuel system needs anti-corrosion protection), uses the same transport and fueling infrastructure, and can be produced nearly anywhere in the world. While ethanol is far cleaner than petrol, it's
nowhere near as clean as hydrogen even if you consider waste generated in producing the latter.


I am not sure hyow hydrogen would be ditributed,
either to the resellers (filling stations)
or regionally (to terminals).
Gasoline is distributed to terminals via pipelines.
MTBE is also distributed via pipelines. But MTBE
pollutes ground water.
Ethanol is shipped via trucks, no pipelines.

Any thoughts on hydrogen distribution?


Once oil is refined into gasoline (aka petrol), it is shipped to filling
stations nearly exclusively via rail and truck tankers, at least in the US.
Hydrogen would be distributed the same way. Natural Gas is the only fuel
commonly transported via pipeline to consumers, and that makes it attractive
in the near term, but CNG and LNG aren't long-term solutions for clean
energy.

Transporting large masses of H2 isn't nearly as safe as petrol, for obvious
reasons, but this is mostly offset because hydrogen can be produced anywhere
electricity is available, removing the need to ship it long distances around
the world or even around a state/province. In theory, every filling station
could produce their own, removing transport from the picture entirely, but I
doubt that's cost-effective.

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

Nov 14 '05 #107
"Thomas G. Marshall" wrote:
CBFalconer <cb********@yah oo.com> coughed up the following:
Stephen Sprunk wrote:
"Corey Murtagh" <em***@slingsho t.no.uce> wrote in message

... snip ...

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

I assume that $20 is after inflation, which means it'll be on par
(in constant dollars) with what we pay for petrol or ethanol
today. Hardly a problem, though I'd expect us all to be running
on hydrogen by then; ethanol is a transition fuel.


And where does the power to extract that hydrogen come from?


Nuclear power plants.


Now you are really trying to pull my chain. Better known as a
silly way to boil water. If you could propose a way of nullifying
the waste products, that would be one thing. Hiding them under
the rug for future generations does not count. Take a look at the
chart of the nuclides, and the products of uranium fission,
sometime.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

Nov 14 '05 #108
"Stephen Sprunk" <st*****@sprunk .org> wrote in message
news:22******** *************** *******@news.te ranews.com...
Transporting large masses of H2 isn't nearly as safe as petrol, for obvious reasons


I'm sorry, but what are the reason Hydrogen is less safe than petrol or
natural gas?

--
Mabden
Nov 14 '05 #109
On Fri, 28 May 2004 22:10:12 GMT, in comp.lang.c , "Stephen Sprunk"
<st*****@sprunk .org> wrote:
"Villy Kruse" <ve*@station02. ohout.pharmapar tners.nl> wrote in message
news:slrncbdqb n.3m8.ve*@stati on02.ohout.phar mapartners.nl.. .
Besides, the problem is just a small
subset of a bigger issue, namely the maximum number that can be stored
in a given variable.
My favorite real world example is when the NASDAQ lost hundreds of thousands
of trades one day due to a fixed-length field in their protocol.


I have a similar example but with a less happy outcome. Turned out the
print format for the amounts was fixed-width, 8 spaces. No room for minus
signs on large trades.... oops.
On another instance, someone made a column too narrow on a spreadsheet, so
the first 2 digits got hidden. 255000000 looked like 5000000.... double
oops.
This is a large
part of why it still takes 7 to 14 days for a check to clear even if it's
from a bank across town -- they know better than to trust their programmers.


Nah, thats just so we can earn 7-14 days interest off you suckers. :-)

(actually, its one of life's little mysteries. If we didn't trust our
programmers, would banks really transact trillions of dollars of FX, equity
and derivatives trades per day, many for same-day-settlement or at best
T+1? Believe me, there is no way banks can check off all those trades in
<24 hours...)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #110

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.