The Year 2038 Problem

[jpd]

Hm I might not make that. Fun prospect!

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?

 

[j.j.haak]

Op Fri, 28 May 2004 08:26:05 GMT schreef "Mabden"
<[email protected]>:

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

Why do you think we live in the year 2004 Anno Domini?

Coos

 

[Michael Wojcik]

http://www.rinkworks.com/stupid/cs_y2k.shtml

Many stupid people making many stupid claims about a topic does not
mean the topic itself is stupid.

Really, Joona, I'm tempted to invoke Pop's Instruction here. I can't
think of a single subject of significance for which there *aren't* a
bunch of ignorant misconceptions. These anecdotes demonstrate
nothing whatsoever about the Y2K problem and its remediation, and I
can't for the world imagine why you would believe otherwise.

Either you participated in Y2K problem investigation and/or remediation,
and therefore know something about it, or you did not and do not.

 

[Gordon Burditt]

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 think I also saw "Y2K-compatible" printer *PAPER* advertised in
stores.

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.
No writing in "19" or "20" in front of a 2-digit year on computer-printed
checks. Some employees at that store were grumbling that their
paychecks still had 2-digit years on them.

There were a bunch of ads for "Y2K-compatible" watches. Most of
those watches were really old and didn't even indicate the day of
the week or the day of the month, much less the year. But they
WERE "Y2K-compatible"! Somebody even tried to make watches Y2K
compatible by sticking tape over the month and the year display,
and charge double for that.

The watch I am wearing now (uses a battery, but the display is good
old-fashioned hands pointing at numbers on a clockface, no LED,
LCD, or anything like that) indicates the day of the month and the
day of the year, but you can't set the month or the year, and at
the end of any month shorter than 31 days you have to reset it. I
did make sure to change the battery in it before the year 2000, on
the possibility that I might have trouble getting one later (a
problem which never materialized) plus it was getting weak anyway.

Gordon L. Burditt

 

[Michael Wojcik]

[Snipped most of the newsgroups, as this troll thread was ridiculously
crossposted.]

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 Wojcik (e-mail address removed)

They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James

 

[Christian Bau]

There were a bunch of ads for "Y2K-compatible" watches. Most of
those watches were really old and didn't even indicate the day of
the week or the day of the month, much less the year. But they
WERE "Y2K-compatible"! Somebody even tried to make watches Y2K
compatible by sticking tape over the month and the year display,
and charge double for that.

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.

 

[Mabden]

Op Fri, 28 May 2004 08:26:05 GMT schreef "Mabden"
<[email protected]>:



Why do you think we live in the year 2004 Anno Domini?

Popes used to have too much control...?

People believe in fairy God fathers...?

The Chinese numbers were bigger than Christians could count...?

Counting things that are old is more fun using negative numbers...?

Them pesky Romans. I don't know why, but I bet it had something to do with
them pesky Romans...!

Abacus' were about to roll over, and everyone was panicking...?

And the number VII reason why we live in the year 2004AD:

God knows!

 

[Stephen Sprunk]

Bob Day <[email protected]> scribbled the following



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?

There were one or two specific model-years from a specific car manufacturer
that stopped working at the rollover (GMT). While I'm sure it was traumatic
for the people it happened to while driving, there had been recalls (free
fix) for those problems in place for half a decade. In any case, it was far
less than 1% of the vehicles on the road, which means it was a non-event
compared to all the media hype.

Unrelated anecdote:

In January 2000, I got an electric bill for the period X Dec 1999 to X Jan
1900, which I just laughed off since the amount billed was correct. A few
days later, I got a "corrected" bill for the period X Dec 2099 to X Jan
2000, with the same amount due. A week later I got yet another bill, this
time for the period X Dec 99 to X Dec 00, and again for the same amount. It
appears the programmers had hard-coded the century that was printed even
though the billing calculations were correctly done with modulo 100 math.
Gotta love COBOL.

S

 

[Stephen Sprunk]

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. It seems
they used a six-digit sequence number for transactions, and the first day
that counter rolled over (in the late 90s) the trading computers would
correctly process the trades but fail to record them anywhere. Fortunately
there was an ultra-paranoid person at some institution who insisted on
printing every trade as it came off the wire (before processing), so after
the necessary bug fixes were done the exchange and its brokers were later
able to re-enter all the data without customers finding out there'd been a
problem.

Every banking system has humans in the loop _somewhere_ in case something
goes wrong, whether it's from fraud or just software bugs. 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.

S

 

[Stephen Sprunk]

I don't hope time_t isn't as often converted to int as size_t is. Well I
guess it won't be that big problem, I just wanted to point out that you
never should assume what other coders think.

Neither time_t nor size_t is ever converted to int in code I write or
maintain; I can't speak to what others do...

With the growing adoption of 64-bit desktops we already see bugs where
people improperly convert size_t to int, at least on platforms where int
isn't also 64-bit (i.e. AMD64). We'll find out how many people don't use
time_t correctly in 2038

S

 

[Stephen Sprunk]

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

 

[Dale Henderson]

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

I was actually tasked with fixing one of these "y2k Bugs".

I had to rewrite a CGI script for the Air Force. The old one only
cared about the last 2 digits of the year I had to modify the
script to accept all 4 digits. (Presumably the air force can't infer
that a birthday marked 82 means 1982 and not 2082 (or 1882) and
has to be explicitly told.) Of course this broke the badly
designed reporting format that the marketing company used and that
had to be redone too.

Quite a bit of work so it could be labeled Y2K compliant and make
DoD happy when the original script was quite sufficient.

 

[Joe Wright]

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.

 

[Dik T. Winter]

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

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

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

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

 

[Nick Landsberg]

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

 

[Dik T. Winter]

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

 

[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?