473,839 Members | 1,611 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 10592
"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******** *******@yahoo.c om...
Stephen Sprunk wrote:
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? 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.


Hydrogen isn't the original source; however, it is a clean, portable way to
store and transport energy generated by some other means. Depending on the
original source, the entire system may or may not be clean, and there's
varying values of "clean" as well.

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.

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 #91
CBFalconer wrote:
Richard Tobin wrote:
Alan Balmer <al******@spamc op.net> wrote:

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?

The only reason it didn't happen was because we fixed it.


Really? People upgraded their coffee makers and spark plugs?

Yup. I had to flash 5 bioses for those items.


I had a computer (still have it) built in 1995 with AMD486DX100 and
32 MB of RAM. When 1999 rolled over into 2000 I expected Somthing to
happen. I didn't. Y2K for this machine was a non-event.

But if you guys did prevent it for me, thanks.

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #92
In article <uv************ ******@newsread 1.news.pas.eart hlink.net> "xarax" <xa***@email.co m> writes:
....
Back around 1983 at Southern California Edison, there was
a panic in their mainframe data center. SCE printed their
paychecks, as well as managing all of their accounting on
their own IBM mainframe system (using COBOL). The paychecks
were printed monthly. The panic happened when some executives
were seeing asterisks appearing in their paychecks. It turns
out that the COBOL programmers never imagined the possibility
of someone getting a monthly paycheck for more than $9,999.99
and when that finally happened, the dollar amount appeared
as **,****.** and invalidated the paychecks.


On a less intrusive scale. I have seen print-outs for people that
displayed the number of days they were still allowed to take off
as ***. (If I am right I have still a holiday allotment of some
100 days this year. I never made it over 999 days.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #93
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?"
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #94
In article <c9********@lib rary1.airnews.n et> go***********@b urditt.org (Gordon Burditt) writes:
There were a few stores around December 1999 that started refusing
non-Y2K-compatible checks (Those with 19__ pre-printed on them).
They eventually relented to the extent that you were allowed to
cross out the 19__ and handwrite in a full 4-digit year. But if
any part of the date was handwritten, it *ALL* had to be handwritten.


They had not learned from the checks with 196_ pre-printed on them?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #95
In article <ch************ *************** ******@slb-newsm1.svr.pol. co.uk> Christian Bau <ch***********@ cbau.freeserve. co.uk> writes:
There is one company that proudly produces a very VERY expensive
non-Y2100 compatible watch. It is a mechanical watch, and displays year,
month, day and weekday correctly until March 1st 2100. At that time,
some part has to be replaced, but the replacement is already included in
the price when you buy it today.


What will it do in 2800 (or 2700, i disremember), when the Greek Orthodox
church and the Gregorian calendar will disagree?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #96
Dik T. Winter wrote:
In article <ch************ *************** ******@slb-newsm1.svr.pol. co.uk> Christian Bau <ch***********@ cbau.freeserve. co.uk> writes:
> There is one company that proudly produces a very VERY expensive
> non-Y2100 compatible watch. It is a mechanical watch, and displays year,
> month, day and weekday correctly until March 1st 2100. At that time,
> some part has to be replaced, but the replacement is already included in
> the price when you buy it today.


What will it do in 2800 (or 2700, i disremember), when the Greek Orthodox
church and the Gregorian calendar will disagree?


The two calendars disagree right now. As far as I know, there
are branches of the Orthodox Church which never recognized
Pope Gregory's adjustments. Thus, even centuries *not*
divisible by 400 *were* leap years in the old calendar.

Right now the calendar difference is 13 days. Thus, Dec. 25th by the
old (Julian) calendar falls on Jan. 7th by the Gregorian calendar.

The computation for Easter is too complex to post right now.
And I'm not sure I can get it right. Suffice it to say, that
Orthodox Easter is sometimes the same date (such as this year),
sometimes a week different, and sometimes as much as
4 or 5 weeks different.

What this has to do with 'c' is beyond me, unless
one wants to write a conversion routine. Even that
is trivial if one knows the rules :)

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Nov 14 '05 #97
In article <HY************ ********@comcas t.com> Joe Wright <jo********@com cast.net> writes:
I had a computer (still have it) built in 1995 with AMD486DX100 and
32 MB of RAM. When 1999 rolled over into 2000 I expected Somthing to
happen. I didn't. Y2K for this machine was a non-event.

But if you guys did prevent it for me, thanks.


I hooked up a MacPlus to my desktop just a few weeks ago. It had not been
in use a few years. Apparently they did prevent for me too.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #98
q
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?

Stephen Sprunk wrote:
"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******** *******@yahoo.c om...
Stephen Sprunk wrote:
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? 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.


Hydrogen isn't the original source; however, it is a clean, portable way to
store and transport energy generated by some other means. Depending on the
original source, the entire system may or may not be clean, and there's
varying values of "clean" as well.

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.

S


Nov 14 '05 #99
Gerry Quinn <ge****@DELETET HISindigo.ie> coughed up the following:
In article <nZ************ *****@nwrdny03. gnilink.net>,
xx*****@yyyyyyy .com says...
"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,

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

Like whom? It seems to me that every software installation of major
worth, regardless of the country, was checked and fixed and rechecked,
etc.

I still think that the y2k thing is real----I'm worried. Is it over
yet?


--
Everythinginlif eisrealative.Ap ingpongballseem ssmalluntilsome oneramsitupy
ournose.
Nov 14 '05 #100

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.