Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

2000 and the computer

0 views
Skip to first unread message

David B. Greene

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

bill...@aol.com (BillH1108) wrote:

>I hope to hear from someone who has really good mainframe skills who can
>put this 2000 problem into prespective. We got into a really torrid
>discussion at a MENSA meeting about the 2000 problem. I took the position
>that there is no substantial problem, but that the computer programer
>consulting firms were creating a dragon and then slaying it. I asked what
>was the "exact" description of the problem. The closest I got to an exact
>explanation was that most of the "older" computer programs looked at a
>date only by the last two numbers and for computational or other output,
>just added a "19" before it. The machines, therefore had no capability to
>write a date with any number other than 19, as the prefix. I can't
>believe that this is a "multi-billion dollar problem". One guy said that
>there are millions of mortgage lenders that will not be able to compute
>the payments. Is this real? I would just like to be told what the exact
>problem is, or be told where (preferably on the internet) that I can find
>a good exposition of this potential crisis.

OK, here's the deal, Bill. Programmers are inflating the problem to
sell the public on the need for their services as the public is getting
feed up to their eyeballs with cost over runs on defective computer
projects. That is why, right now, programmers "don't get no respect"
like real engineers and scientists do. So, to keep their collective
butts out of the unemployment line, they have rallied around their savior,
Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
because they know the problem will be easy to fix and they wll look like
heros for once and maybe even get a TV documentry on how they "saved"
civilization.


Thomas R. Truscott

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

>>I hope to hear from someone who has really good mainframe skills who can
>>put this 2000 problem into prespective.

This is not just a "mainframe" or even conventional "computer" problem.
We will have plenty of trouble just with the Global Positioning Systems (GPS).
For example,
http://catless.ncl.ac.uk/Risks/18.24.html#subj3
points out that many GPS receivers manufactured to date
will start malfunctioning at 0000 22 Aug 1999.
This is due to a roll-over that is part of the GPS spec.
(Apparently one or two manufacturers noticed the hazard,
but kept quiet to gain a competitive advantage.)
Since GPS prices have been following, the cheapest fix
is probably to to throw away the other units and buy new ones.

But potential GPS y2k problems go much deeper than that.
A recent study uncovered about a dozens different ways that GPS
can go awry due to problems related to y2k.
(Sorry, I don't have a reference.)

One aspect of this problem is that digital systems use finite arithmetic,
somewhat like a car odometer, and when the number "rolls over"
bad things can happen unless special care is taken.
But only rarely is such care taken, and even then people often get it wrong.
This has caused numerous problems in computers over the years.
The special thing about the year 2000 is that LOTS of
odometers roll over then, and we can expect LOTS of problems.
The problem is not so much the difficulty of fixing the problems
as it is the disruption that will be caused while the systems are down.

One source of info on the y2k problem is http://www.year2000.com
Are some people over-hyping this problem? Sure.
But that is better than what most people are doing about it.

Tom Truscott

Robert Israel

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

bill...@aol.com (BillH1108) wrote:

|> I hope to hear from someone who has really good mainframe skills who can

|> put this 2000 problem into prespective. We got into a really torrid
|> discussion at a MENSA meeting about the 2000 problem. I took the position
|> that there is no substantial problem, but that the computer programer
|> consulting firms were creating a dragon and then slaying it. I asked what
|> was the "exact" description of the problem. The closest I got to an exact
|> explanation was that most of the "older" computer programs looked at a
|> date only by the last two numbers and for computational or other output,
|> just added a "19" before it. The machines, therefore had no capability to
|> write a date with any number other than 19, as the prefix. I can't
|> believe that this is a "multi-billion dollar problem". One guy said that
|> there are millions of mortgage lenders that will not be able to compute
|> the payments. Is this real? I would just like to be told what the exact
|> problem is, or be told where (preferably on the internet) that I can find
|> a good exposition of this potential crisis.

Look at the comp.risks newsgroup for ongoing discussions of the Year 2000
problem. It may sometimes be exaggerated, but it is a substantial problem,
and its effects are already being felt as, e.g., many credit cards and drivers' licenses now have expiration dates >= 2000. It's not so much that the computer
can't write the date 2000, but that it confuses that date with 1900 and either rejects the data completely or calculates that your mortgage payment is 100 years overdue. Compounding the confusion is that many of the older programs are poorly
documented, and it is difficult to check whether there are going to be problems
before the problems actually arise.

Robert Israel isr...@math.ubc.ca
Department of Mathematics (604) 822-3629
University of British Columbia fax 822-6074
Vancouver, BC, Canada V6T 1Y4

Edward Edmondson

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

"David B. Greene" <da...@antispam.hacyon.com> wrote

>bill...@aol.com (BillH1108) wrote:
>
>>I hope to hear from someone who has really good mainframe skills who can
>>put this 2000 problem into prespective. We got into a really torrid
>>discussion at a MENSA meeting about the 2000 problem. I took the position
>>that there is no substantial problem, but that the computer programer
>>consulting firms were creating a dragon and then slaying it. I asked what
>>was the "exact" description of the problem. The closest I got to an exact
>>explanation was that most of the "older" computer programs looked at a
>>date only by the last two numbers and for computational or other output,
>>just added a "19" before it. The machines, therefore had no capability to
>>write a date with any number other than 19, as the prefix. I can't
>>believe that this is a "multi-billion dollar problem". One guy said that
>>there are millions of mortgage lenders that will not be able to compute
>>the payments. Is this real? I would just like to be told what the exact
>>problem is, or be told where (preferably on the internet) that I can find
>>a good exposition of this potential crisis.
>
>OK, here's the deal, Bill. Programmers are inflating the problem to
>sell the public on the need for their services as the public is getting
>feed up to their eyeballs with cost over runs on defective computer
>projects. That is why, right now, programmers "don't get no respect"
>like real engineers and scientists do. So, to keep their collective
>butts out of the unemployment line, they have rallied around their savior,
>Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>because they know the problem will be easy to fix and they wll look like
>heros for once and maybe even get a TV documentry on how they "saved"
>civilization.
>
The British Houses of Parliament had a report done. Go to
http://www.parliament.gov.uk/ [ I think ] and work through the POST
(Parliamentary Office of Science and Technology) and download the
relevant PDF Acrobat file.
--

Edward Edmondson
Feel free to contradict.
Mail me as: edw...@yendor.demon.co.uk

Jay R. Ashworth

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

Craig Yourdon has nothing to do with this.

And, in fact, it's already causing problems in "the real world".
Here's but one simple example:

Do you have a credit card?

They have expiration dates, some time in the future.

The terminals you swipe them through when you want to buy something
compare the expiration date on the card to today's date, to see if your
card is still valid, or should be rejected.

So, now, it's 1997, and your card expires in three years.

In 2000.

So the expiration date encoded on the card is "04/00".

You buy something, the $5/hr clerk swipes the card, the terminal says
"duh, '00'. That's less than '97'. I guess the card is expired"...
and rejects your purchase.

This has already started happening... Verifone Inc., one of the
manufacturers thereof, is working to fix the problem... but in the mean
time, several card issuers have had to recall cards expiring in 2000.

So, no, it's not a straw man, cooked up by the computer industry for
any reason at all, and it's the _height_ of malice to minimize the
problem this way.

Yes. Malice.

For more information, go read http://cnn.com/TECH/9601/2000/index.html,
and the resources it points to.

And be afraid. Be _very_ afraid.

Cheers,
-- jra

--
Jay R. Ashworth j...@scfn.thpl.lib.fl.us
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "To really blow up an investment house requires
Tampa Bay, Florida a human being." - Mark Stalzer +1 813 790 7592

Daniel Zepeda

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

I hate it when people that have absolutely no idea what they are talking
about chime in with misinformation and make it seem like they have got the
answers. Mr. Green, sure its a simple problem, all you have to do is change
a few lines of code to compensate. The cost and "sky is falling" comes in
because those few lines of code are buried in literally millions of lines
of code that have to be searched through and corrected. The few lines of
code have to be changed in thousands of places, making it a huge job. As a
simple illustration of the problem, suppose, Mr. Green, that I have a penny
laying on the ground face up, and a gun to your head. I say "I want the
penny face down now, or I'll shoot you." No problem right? Simple
operation, just turn the penny over, what is so difficult about that? Now,
suppose that I have an *entire salt lake* covered with face up and face
down pennies. I say "Mr. Green, I want all of the pennies face down in 1
month, or I'm going to shoot you." Simple operation, right? All you have to
find the face up pennies and turn them over. What is so hard about that?
Would you be worried? I would if I were the one having to turn the pennies
over.

Bill, there is a good discussion of the topic at
http://www.year2000.com/y2kbio.html.

Dave Rusin

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

bill...@aol.com (BillH1108) wrote:

>One guy said that
>there are millions of mortgage lenders that will not be able to compute
>the payments. Is this real?

This is precisely the example I use to suggest the problem is _not_ quite
as extensive as it is sometimes made out to be. Most people in the US who have
purchased a house in the last _quarter century_ have contracts which
expire in a year past 2000. Clearly banks have for some time had software
which can express these dates, and even (for example) provide payment
schedules which include them.

More generally, the image presented of a vast blinking-out of everything
computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
far-fetched. Certainly a number of unexpected glitches will occur from
computers on autopilot, but we expect most major systems will be the
objects of at least some experimentation before 2000, during which time
the likely problems will be discovered.

Having said that, I would like to point out that it _is_ important to
run such experiments! Especially for complex integrated systems, time is
running out if it is to be hoped that corrections or replacements can be
in place in 33 months. Massive operations such as the IRS are already
working on this issue, but all of us who use machines have a duty to
see what our hardware and software will do. Unless you take the date from
some external source, these experiments are usually easy.

For example, if you use a PC, set the date to 31 Dec 1999 and
the time to 23:58, shut it off, and come back in 3 minutes. If the date
is not 1 Jan 2000, you now know that your operating system will feed
incorrect data to all your programs after that day; you have a couple of
years to save up for a new machine. I'm in that position (although there's
an old XT in the basement which thinks every day is 1 Jan 1980 and it can
still crunch numbers, so I keep it; my present machine may have the same fate).

Do you use an old version of Quicken? Try writing a check dated in 2000.
It may not let you do so. I don't want to have to run out for new software
while trying to pay bills in Jan 2000, so I tested my copy and now I know it's
time to upgrade.

Little of my other software is date-dependent. Nowadays when I notice
a date field, I try crossing the century mark. Software that messes up
I don't use. Fortunately I'm not very integrated into the date-conscious
world anyway :-).

If you're basically computer-savvy, and use fairly limited systems,
you can discharge your responsibilities in the Y2K problem. If you're
prone to paranoia, or if you're in charge of a major date-dependent
system, it's past time to begin scrutiny.

dave

Dene Bebbington

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

"David B. Greene" <da...@antispam.hacyon.com> wrote:
>bill...@aol.com (BillH1108) wrote:
>
>>I hope to hear from someone who has really good mainframe skills who can
>>put this 2000 problem into prespective. We got into a really torrid
>>discussion at a MENSA meeting about the 2000 problem. I took the position
>>that there is no substantial problem, but that the computer programer
>>consulting firms were creating a dragon and then slaying it. I asked what
>>was the "exact" description of the problem. The closest I got to an exact
>>explanation was that most of the "older" computer programs looked at a
>>date only by the last two numbers and for computational or other output,
>>just added a "19" before it. The machines, therefore had no capability to
>>write a date with any number other than 19, as the prefix. I can't
>>believe that this is a "multi-billion dollar problem". One guy said that

>>there are millions of mortgage lenders that will not be able to compute
>>the payments. Is this real? I would just like to be told what the exact
>>problem is, or be told where (preferably on the internet) that I can find
>>a good exposition of this potential crisis.
>
>OK, here's the deal, Bill. Programmers are inflating the problem to
>sell the public on the need for their services as the public is getting
>feed up to their eyeballs with cost over runs on defective computer
>projects.

Whilst programmers are largely responsible for the problem, they are
definitely not inflating this problem which does exist, consider just
how much software there is in the world and this is no minor issue.
There are many applications which will produce incorrect results in the
year 2000, and just the investigative work on projects will be enormous,
plus there's then the costs of fixing and regression testing.

> That is why, right now, programmers "don't get no respect"
>like real engineers and scientists do. So, to keep their collective
>butts out of the unemployment line,

Hardly, here in Britain there's plenty of work in software, with demand
for programmers apparently outstripping supply, at least supply of good
people with the right skills. The year 2000 problem will just lead to
extra work on top of this, work which I might add that many programmers
do not get very excited about - after all who wants to trawl other
people's code just to fix date based bugs?!

> they have rallied around their savior,
>Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>because they know the problem will be easy to fix and they wll look like
>heros for once and maybe even get a TV documentry on how they "saved"
>civilization.

Well, for all sorts of reasons programmers are the culprit in the first
place, so they're hardly heroes. As for Yourdon he is not viewed as a
saviour by anyone in the software industry that I've spoken to.

--
Dene Bebbington

"I mean, who would have noticed | "It is impossible to enjoy idling
another madman around here?!" | thoroughly unless one has plenty
- Blackadder | of work to do." - Jerome K Jerome

Eugene A. Pallat

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

David B. Greene <da...@antispam.hacyon.com> wrote in article
<5ikkij$g9f$4...@brokaw.wa.com>...


> bill...@aol.com (BillH1108) wrote:
>
> >I hope to hear from someone who has really good mainframe skills who can
> >put this 2000 problem into prespective. We got into a really torrid
> >discussion at a MENSA meeting about the 2000 problem. I took the
position
> >that there is no substantial problem

snip


>
> OK, here's the deal, Bill. Programmers are inflating the problem to
> sell the public on the need for their services as the public is getting
> feed up to their eyeballs with cost over runs on defective computer
> projects

snip

The problem is far worse that you people can even imagine. There are
already people who have had credit card purchases rejected because the
expiration date of "00" interprets to 1900 - ergo expired card.

The are computer systems that WILL lockup or crash. On the mainframes,
tape expiration dates are of the form YYDDD and they will automatically be
scratched.

Whether you realize it or not, the companies that do are almost panic
stricken The "dinosaur" COBOL programmers are getting big bucks to fix
this problem.

Try setting the date and time on your PC to 12/21/99 24:55 and power off.
Turn it back on after 10 minutes and see what happens. Most of them will
have a problem. Supposedly NT can survive.

Remove the '.' from orion.data for sending email to me.

Gene eapa...@orion.data.com

Orion Data Systems

Solicitations to me must be pre-approved in writing
by me after soliciitor pays $1,000 US per incident.
Solicitations sent to me are proof you accept this
notice and will send a certified check forthwith.

Larry Anderson & Diane Hare

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

> bill...@aol.com (BillH1108) wrote:
>
> >I hope to hear from someone who has really good mainframe skills who can
> >put this 2000 problem into prespective. We got into a really torrid
> >discussion at a MENSA meeting about the 2000 problem. I took the position
> >that there is no substantial problem, but that the computer programer
> >consulting firms were creating a dragon and then slaying it. I asked what
> >was the "exact" description of the problem. The closest I got to an exact
> >explanation was that most of the "older" computer programs looked at a
> >date only by the last two numbers and for computational or other output,
> >just added a "19" before it. The machines, therefore had no capability to
> >write a date with any number other than 19, as the prefix. I can't
> >believe that this is a "multi-billion dollar problem". One guy said that
> >there are millions of mortgage lenders that will not be able to compute
> >the payments. Is this real? I would just like to be told what the exact
> >problem is, or be told where (preferably on the internet) that I can find
> >a good exposition of this potential crisis.
>

>From what I've read and my opinion...(It's an opinion, not an invitation
to flaming, ok?)

* Many programs that use the two digit years are older programs designed
for older machines (some of these programs were originally developed in
the 60s and 70s).

* Some of these programs do not have source code (or incomplete source
code, lost over the years).

* Some of the languages/compilers used to create said programs cannot
operate on the current hardware the programs are currently running,
making the source code inaccessible unless translated to newer
development platforms.

* There are vast amounts of data containing two digit years that will
have to be interpreted when comparing against updated data, or read and
re-recorded in the new format (think birthdates in DMV, Social Security,
etc. files.)

* Federal/State Government are doing cost reductions and does not have
any inclination to fund any data/program conversions, so many agencies
have to do this extra work (as well as performing their normal work, on
schedule, with the same -or possibly cut- budget.)

* There are a bunch of different schemes to correcting the year 2000
problem (from 2 to 4 digit conversion to offset algorithms, etc.) and
some programmers are stubburn about not using 'their idea' (nothing new
there).

* If I were a programmer on one of those projects I would be inclined to
do a lot more updating to the code than just the date, and that of
course takes time...

* The computer consulting firms ARE hyping it up in hopes to rake in the
bucks, but since government is buracracy and and more re-active than
pro-active, they will proabably stall till the last minute and panic at
the end.

Larry Anderson

P.S. Most of the dilemma will be for projects that track spans of time
between dates, such things as age calculation, billing periods, fiscal
years, etc. You will see alot of folks freak out on Jan 1, 2000 because
their accounting packages mess up. After that it will be just mainly
those with date/time span tracking problems. 12/31/99 to 01/01/00. is
-99 years to a computer.
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Visit our web page at: http://www.goldrush.com/~foxnhare
Call our BBS (Silicon Realms BBS 300-2400 baud) at: (209) 754-1363
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Maryse Turcotte

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

Hello!

I've always wondered why programmers didn't use 4 digits date in the
first place. The best explanation I could come up with was of course that
it must have been a way to economize on storage and time of execution which
I heard was very costly back then... Still, I find it hard to believe
that they didn't anticipate the problem which wasn't that far away...

???

Thanks in advance.

Maryse Turcotte

E-mail : maryse....@sympatico.ca

do...@no.spam

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

In article <334F0C...@sympatico.ca>, maryse....@sympatico.ca
says...

> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course that
> it must have been a way to economize on storage and time of execution which
> I heard was very costly back then... Still, I find it hard to believe
> that they didn't anticipate the problem which wasn't that far away...

Well....

'WE' had to scrape and scrounge every last bit of RAM
and CPU cycles to make 'our' software usable.
As to anticipating the problem:

a) Not my problem.

b) Who woulda thought someone would still be using this in 20xx?

c) It works, doesn't it?

But seriously folks,
How many of you are going to need new checkbooks on
1/1/00?

All my checks start with '19__'
Who the hell is going to honor a check written in 1900?

My thoughts, your actual thoughts may vary,
Doug

p.s.
Yes, I'm a programmer.


--

Remove 'REMOVE_ME' from address below to reply
mailto: spamless@REMOVE_MEpacbell.net

Spam: It's not just for breakfast anymore.

For help in joining the war on SPAM:

http://www.rlabs.com/sputum/sputools.html
http://kryten.eng.monash.edu.au/gspam.html
http://spam.abuse.net/spam/
http://www.cnet.com/Content/Features/Howto/Spam/ss02.html

David Carrell

unread,
Apr 11, 1997, 3:00:00 AM4/11/97
to

In article <5ilu26$6uo$7...@news.usf.edu>,

j...@scfn.thpl.lib.fl.us (Jay R. Ashworth) wrote:
>David B. Greene (da...@antispam.hacyon.com) wrote:
>: bill...@aol.com (BillH1108) wrote:
>: >I hope to hear from someone who has really good mainframe skills who can
>: >put this 2000 problem into prespective. We got into a really torrid
>: >discussion at a MENSA meeting about the 2000 problem. I took the
position
>: >that there is no substantial problem, but that the computer programer
>: >consulting firms were creating a dragon and then slaying it. I asked
what
>: >was the "exact" description of the problem. The closest I got to an
exact
>: >explanation was that most of the "older" computer programs looked at a
>: >date only by the last two numbers and for computational or other output,
>: >just added a "19" before it. The machines, therefore had no capability
to
>: >write a date with any number other than 19, as the prefix. I can't
>: >believe that this is a "multi-billion dollar problem". One guy said
that
>: >there are millions of mortgage lenders that will not be able to compute
>: >the payments. Is this real? I would just like to be told what the exact
>: >problem is, or be told where (preferably on the internet) that I can
find
>: >a good exposition of this potential crisis.
>
>: OK, here's the deal, Bill. Programmers are inflating the problem to
>: sell the public on the need for their services as the public is getting
>: feed up to their eyeballs with cost over runs on defective computer
>: projects. That is why, right now, programmers "don't get no respect"
>: like real engineers and scientists do. So, to keep their collective
>: butts out of the unemployment line, they have rallied around their
savior,
>: Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>: because they know the problem will be easy to fix and they wll look like
>: heros for once and maybe even get a TV documentry on how they "saved"
>: civilization.
>
>Craig Yourdon has nothing to do with this.
>
>And, in fact, it's already causing problems in "the real world".
>Here's but one simple example:
>

< CLIPPED >

Here is another about to hit some users of VMS fro DEC.

Briefly, Unix (and also VMS) use(d) the time origin of 1-Jan-1970. On
19-May-1997 the time delta from then will be 10,000 days. Some VMS system
calls will fail when the time delta becomes >= 10,000. So on 19-May-1997 (or
there about, some VAXEN will experience anomalies. For more precise info and
details see:
http://www.openvms.digital.com/openvms/letter.html

This is a much smaller (and easier) problem to fix. Yes, I feel sometimes
the media (general and computing) a) get the problem wrong and b) exagerate
its significance but I do know the a) it is a real problem, b) will have
financial impact, c) is going to 'bite' some people/companies.

Another factoid to lend credance to the problem is that the SEC (the stock
market guys) are interested in companies plans/response. Not because they
think the market will be shut down but they feel that the cost of the fix
AND/OR the cost of NOT fixing the problem in time MAY impact some companies
financial performance significantly.

No I do not work in the computer field directly. I am only a user (work and
recreation) who is working/watching to minimize any impact on me and mine.

DAC


-------------------------------------------------------------------------
David Carrell All comments above are mine, and
Process Control Engineer do not necessarily reflect the
Conoco, Inc. opinions of Dupont and/or Conoco,
*carrelda*@pore.dnet.dupont.com* [and why should they]
(return address altered to reduce
adds, remove *'s for real address)

akrolak millcomm.com

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In article <5ikkij$g9f$4...@brokaw.wa.com>, da...@antispam.hacyon.com says...

>OK, here's the deal, Bill. Programmers are inflating the problem to
>sell the public on the need for their services as the public is getting
>feed up to their eyeballs with cost over runs on defective computer
>projects. That is why, right now, programmers "don't get no respect"
>like real engineers and scientists do. So, to keep their collective
>butts out of the unemployment line, they have rallied around their savior,
>Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>because they know the problem will be easy to fix and they wll look like
>heros for once and maybe even get a TV documentry on how they "saved"
>civilization.
>

I used to work for a company that did the IS for a major auto
manufacturer. Year 2000 problems were already being addressed,
though generally as a side issue, but we did encounter stuff
where fixes had to be made immediately. For example, consumer
relations cases were assigned 'expiration' dates - how long we
kept the case in the online database before we purged it out. Different
types of cases get kept for different lengths of time. In january
1995 we had to change the database to a 4 digit year - some cases
needed expiration dates 5 years out.

In most cases, data isn't independant - its used by multiple programs,
sometimes sent to multiple companies. Data format changes must be
carefully coordinated, or you break multiple processes.

Worse yet, you may be running object code that you no longer have
the source for, or, if you do have the source, its written in a
much older version of a language, and you need to modify it just
to get it to compile.

It adds up.

--
Paul Krolak
akrolak(at)millcomm.com


Bruce Glassford

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
wrote:

>bill...@aol.com (BillH1108) wrote:
<snip>


>
>More generally, the image presented of a vast blinking-out of everything
>computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
>far-fetched. Certainly a number of unexpected glitches will occur from
>computers on autopilot, but we expect most major systems will be the
>objects of at least some experimentation before 2000, during which time
>the likely problems will be discovered.
>

<snip>
An interesting discussion arose at lunch today about the Y2K problem
(hey, we're all in the computing/management consulting business - why
talk about something interesting?). Someone made the point that he
didn't want to rely on any imbedded system on January 1, 2000, but
didn't worry about financial systems until December 31, 2000, when
they'll all go crazy trying to do year end. Also, there will be an
interesting test on March 1, 2000 - let's see how many programmers
caught the fact there's no February 29, 2000. (me being lazy, looked
up my old date calculation routine - it will work for 2000, but failed
for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
in the leap year if divided by 100 and the non-leap year if divided by
400 routine)
... Bruce

Lulu of the Lotus-Eaters

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

*}>I hope to hear from someone who has really good mainframe skills who can
*}>put this 2000 problem into prespective. We got into a really torrid
*}>discussion at a MENSA meeting about the 2000 problem.

Ummm gee... somehow this confirms everything I ever thought about MENSA.

Yours, Lulu (nope, no number for me)...

quilty@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
philos. _/_/ Postmodern Enterprises \_\_
umass. _/_/ \_\_ d o
edu _/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e


Chas ('cha-s vb)

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

Correction: There is a February 29th in the year 2000. The rules are:

1. Leap year if year is divisible by four.
2. Not Leap year if year is divisible by 100.
3. Leap year if year is divisible by 400.

--B. Chas Parisher

Tony Quinn

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In article <334f01fe...@news.mindspring.com>, Bruce Glassford
<bglas...@earthling.net> writes

>An interesting discussion arose at lunch today about the Y2K problem
>(hey, we're all in the computing/management consulting business - why
>talk about something interesting?). Someone made the point that he
>didn't want to rely on any imbedded system on January 1, 2000, but
>didn't worry about financial systems until December 31, 2000, when
>they'll all go crazy trying to do year end. Also, there will be an
>interesting test on March 1, 2000 - let's see how many programmers
>caught the fact there's no February 29, 2000. (me being lazy, looked
>up my old date calculation routine - it will work for 2000, but failed
>for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
>in the leap year if divided by 100 and the non-leap year if divided by
>400 routine)

I'm glad you don't write s/w for me - your leap-year algorithm is arse
about face - non-leap when not dividible by 400, leap WHEN divisible by
400.

--
--------------------------------------------------------------
Tony Quinn --- The Voice of Insanity
replies to tony...@sixpints.demon.co.uk
--------------------------------------------------------------

Rick Tyler

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

On 11 Apr 1997 23:48:09 GMT, "Eugene A. Pallat"
<eapa...@orion.data.com> wrote:

:David B. Greene <da...@antispam.hacyon.com> wrote in article


:<5ikkij$g9f$4...@brokaw.wa.com>...
:> bill...@aol.com (BillH1108) wrote:

:The problem is far worse that you people can even imagine.

:The are computer systems that WILL lockup or crash.

:On the mainframes,tape expiration dates are of the form YYDDD and they


:will automatically be scratched.
:
:Whether you realize it or not, the companies that do are almost panic

:stricken.
:
:Try setting the date and time on your PC to 12/21/99 24:55 and power off.

:Turn it back on after 10 minutes and see what happens. Most of them will
:have a problem.

So ...

"Drink, drink, everyone drink,
It's not as bad as they used to think,
With every Manhattan your stomach will flatten,
So drink, drink, drink."

-- Rick "Ashes to ashes, dust to dust, if the A-bomb don't get you,
Strontium must" Tyler

-----------------------------------------------------
"I can 'splain it to you, but I can't understand it
for you" -- Lizz Braver

+ The real address would leave out "goaway" +

Paul Keinänen

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

"Eugene A. Pallat" <eapa...@orion.data.com> wrote:

>David B. Greene <da...@antispam.hacyon.com> wrote in article

>>

>> OK, here's the deal, Bill. Programmers are inflating the problem to
>> sell the public on the need for their services as the public is getting
>> feed up to their eyeballs with cost over runs on defective computer
>> projects

>snip
>
>The problem is far worse that you people can even imagine. There are
>already people who have had credit card purchases rejected because the
>expiration date of "00" interprets to 1900 - ergo expired card.

I did not know that you have credit cards that are valid for many
years, but anyway, there is an easy solution to this problem. All
cards issued before the year 2000 should have a validity date of Dec
31, 1999 (or earlier). New cards are delivered to all customers in
December 1999 and the new cards are valid _starting_ from Jan 1, 2000
and valid until any convenient date in year 200x. Any systems
comparing only the last two digits of the year would still work with
the new cards in year 2000. This arrangement would not need more cards
if the validity period of the old cards would be extended to Dec 31,
1999 if the normal validity period would end in say, August 1999. With
colorful new "2000" cards you could turn the date problem to a great
PR stunt :-).

My point is, in certain circumstances there can be other ways to work
around the date problems than fixing the program.

Brett Frankenberger

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In article <334F0C...@sympatico.ca>,

Maryse Turcotte <maryse....@sympatico.ca> wrote:
>Hello!
>
>I've always wondered why programmers didn't use 4 digits date in the
>first place. The best explanation I could come up with was of course that
>it must have been a way to economize on storage and time of execution which
>I heard was very costly back then...

There's many reasons ... DASD (hard disk) was expensive, core (RAM) was
expensive, a lot of data entry was done via punched cards which
limited you to 80 characters per record, so including the "19" cost you
2.5% of the available columns ... telecom lines were slow so there was a
marginal improvement from not sending 19 to all the remote terminals
... and so on.

>Still, I find it hard to believe
>that they didn't anticipate the problem which wasn't that far away...

They didn't expect that their code would be in use 30 years from when
they wrote it. The 32 bit time in Unix wraps in 2038 or something like
that ... how many programmers writing Unix code today are writing code
that will properly handle that? (No doubt some are, but many aren't).
--

- Brett (bre...@netcom.com)

------------------------------------------------------------------------------
... Coming soon to a | Brett Frankenberger
.sig near you ... a Humorous Quote ... | bre...@netcom.com

Tony Buckland

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In article <xxod8s1...@ringer.cs.utsa.edu>,


Daniel Zepeda <dze...@ringer.cs.utsa.edu> wrote:
>
>I hate it when people that have absolutely no idea what they are talking
>about chime in with misinformation and make it seem like they have got the
>answers. Mr. Green, sure its a simple problem, all you have to do is change

>a few lines of code to compensate. ...

Those few lines of code, however, often access and modify data structures
in which only two characters were reserved to express a date. Changing the
code will be worse than useless unless all those structures are expanded.
Perhaps dozens of routines, perhaps alignment problems where the next
item in the structure was put on a doubleword boundary, perhaps memory
allocation routines that manage instances of the structure; you could end
up with thousands of lines to change, in source which most likely is
minimally documented, in languages and versions thereof that haven't been
used in the organization for years -- and sometimes the source no longer
even exists.

James M. Curran

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In <<5ilu26$6uo$7...@news.usf.edu>>,
j...@scfn.thpl.lib.fl.us (Jay R. Ashworth) wrote:

>So, no, it's not a straw man, cooked up by the computer industry for
>any reason at all, and it's the _height_ of malice to minimize the
>problem this way.

>Yes. Malice.

Well, it's not a "strawman" but it is blown way out of proportion.
Bank's won't have problems with mortgages --- Thay already had the
problems back in 1970 -- when a thirty year mortgage ended in 2000 --
and dealt with it then. Social Security Admin had to deal with this
problem back when the first guy born in 1935 (retiring in 2000) asked
for a SS card.


Truth,
James


Eugene A. Pallat

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

do...@no.spam wrote in article
<MPG.db8bdce6...@news.pacbell.net>...snip

> But seriously folks,
> How many of you are going to need new checkbooks on
> 1/1/00?
>
> All my checks start with '19__'
> Who the hell is going to honor a check written in 1900?
>
> My thoughts, your actual thoughts may vary,

My bank has the printers producing checks with no year. That means that
they could be used in 3417. :-)

Drox

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

Maryse Turcotte wrote:
>
> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course that
> it must have been a way to economize on storage and time of execution which
> I heard was very costly back then... Still, I find it hard to believe

> that they didn't anticipate the problem which wasn't that far away...

Yes, storage was at a premium then, and any extra bits one could squeeze
out of a program was money in the bank, so to speak, so programmers
economized wherever they could. Also, keep in mind that this started
back in the 50's and 60's (there - I'm doing it myself. Should have
said 1950's and 1960's) and the millenium was a very long way away yet,
at least in computer terms. If computer technology had developed a few
decades earlier, the century-turnaround might have been on people's
minds more (having happened more recently), and they might have
accounted for it in their programming. If the development had been
delayed a few more decades the impending millenium would almost
certainly have been considered in the way programmers wrote their
programs. Guess it was just bad luck that early computers with their
expensive memory came along when they did. Oh well...

-Drox

Quantum Leaper

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

Eugene A. Pallat wrote:
>
> do...@no.spam wrote in article
> <MPG.db8bdce6...@news.pacbell.net>...
> > In article <334F0C...@sympatico.ca>, maryse....@sympatico.ca

> > All my checks start with '19__'


> > Who the hell is going to honor a check written in 1900?
> >
> > My thoughts, your actual thoughts may vary,
>
> My bank has the printers producing checks with no year. That means that
> they could be used in 3417. :-)
>

Same with my checks, it says DATE, but look at the deposit slips in the
back? My say 19__ as a date field. So I can write checks til the end
of time but I just can't deposit any money! ;)

Bruce Glassford

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

On 12 Apr 1997 05:22:28 GMT, ch...@ncsu.edu (Chas (\'cha-s\ vb)) wrote:

>On Sat, 12 Apr 1997 03:34:51 GMT, Bruce Glassford <bglas...@earthling.net> wrote:
>>On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
>>wrote:
>>
>>>bill...@aol.com (BillH1108) wrote:
>><snip>
>>>
>>>More generally, the image presented of a vast blinking-out of everything
>>>computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
>>>far-fetched. Certainly a number of unexpected glitches will occur from
>>>computers on autopilot, but we expect most major systems will be the
>>>objects of at least some experimentation before 2000, during which time
>>>the likely problems will be discovered.
>>>
>><snip>

>>An interesting discussion arose at lunch today about the Y2K problem
>>(hey, we're all in the computing/management consulting business - why
>>talk about something interesting?). Someone made the point that he
>>didn't want to rely on any imbedded system on January 1, 2000, but
>>didn't worry about financial systems until December 31, 2000, when
>>they'll all go crazy trying to do year end. Also, there will be an
>>interesting test on March 1, 2000 - let's see how many programmers
>>caught the fact there's no February 29, 2000. (me being lazy, looked
>>up my old date calculation routine - it will work for 2000, but failed
>>for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
>>in the leap year if divided by 100 and the non-leap year if divided by
>>400 routine)
>

>Correction: There is a February 29th in the year 2000. The rules are:
>
>1. Leap year if year is divisible by four.
>2. Not Leap year if year is divisible by 100.
>3. Leap year if year is divisible by 400.
>
>--B. Chas Parisher

Good thing I don't write date routines any more, eh? <blush>
Never could remember that stuff - I tend to just check calendars.
Thanks for the correction.
... Bruce

Hugh Young

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In <334f01fe...@news.mindspring.com> bglas...@earthling.net (Bruce
Glassford) wrote:

>On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
>wrote:
>
>>bill...@aol.com (BillH1108) wrote:
>>Also, there will be an
>interesting test on March 1, 2000 - let's see how many programmers
>caught the fact there's no February 29, 2000. (me being lazy, looked
>up my old date calculation routine - it will work for 2000, but failed
>for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
>in the leap year if divided by 100 and the non-leap year if divided by
>400 routine)

>... Bruce

No, its' the other way around. There wasn't a Feb 29 1900 but there will be
one in 2000.
--
Hugh Young, Pukerua Bay, Nuclear-free Aotearoa / NEW ZEALAND
#158 Welcome to Earth. Do not leave your vehicle.

Don McKenzie

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
<eapa...@orion.data.com> wrote:

[snip]


> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
> Turn it back on after 10 minutes and see what happens. Most of them will

> have a problem. Supposedly NT can survive.
>
Or use a Mac. No problem.

--
Don McKenzie <mca...@wavenet.com>

Republican environmentalists:
Check out <http://www.rep.org>

ecsd

unread,
Apr 12, 1997, 3:00:00 AM4/12/97
to

Daniel Zepeda wrote:

> Bill, there is a good discussion of the topic at
> http://www.year2000.com/y2kbio.html.
>
> da...@antispam.hacyon.com (David B. Greene) writes:
> >
> > bill...@aol.com (BillH1108) wrote:
> >

> > >I hope to hear from someone who has really good mainframe skills who can

> > >put this 2000 problem into prespective. We got into a really torrid

> > >discussion at a MENSA meeting about the 2000 problem. I took the position
> > >that there is no substantial problem, but that the computer programer
> > >consulting firms were creating a dragon and then slaying it. I asked what
> > >was the "exact" description of the problem. The closest I got to an exact
> > >explanation was that most of the "older" computer programs looked at a
> > >date only by the last two numbers and for computational or other output,
> > >just added a "19" before it. The machines, therefore had no capability to
> > >write a date with any number other than 19, as the prefix. I can't
> > >believe that this is a "multi-billion dollar problem". One guy said that
> > >there are millions of mortgage lenders that will not be able to compute
> > >the payments. Is this real? I would just like to be told what the exact
> > >problem is, or be told where (preferably on the internet) that I can find
> > >a good exposition of this potential crisis.
> >

> > OK, here's the deal, Bill. Programmers are inflating the problem to
> > sell the public on the need for their services as the public is getting
> > feed up to their eyeballs with cost over runs on defective computer

> > projects. That is why, right now, programmers "don't get no respect"
> > like real engineers and scientists do. So, to keep their collective
> > butts out of the unemployment line, they have rallied around their savior,
> > Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
> > because they know the problem will be easy to fix and they wll look like
> > heros for once and maybe even get a TV documentry on how they "saved"
> > civilization.

Whoever said "the problem is not real" never coded any systems code
that related to the date.
The poster who mentioned (here or elsewhere) that tapes will be
scratched actually added a very important observation, though I don't
know how the age calculations will be handled.

I'm quite glad that everything I coded from early on handled this
and will not expire until between 2069 and 2088, or even 9999,
depending.

The problem is not only finding and correcting the code, but in many
cases the source code NO LONGER EXISTS. It won't just be a matter
of correcting the code, but making sure the code will still compile,
still makes sense in the current context, etc. and no doubt some
millions and millions and millions of lines of code will just have
to BE REWRITTEN FROM SCRATCH.

Worse (tee hee) yet is that hundreds and thousands of programmers
will have their noses rubbed into MVS system code and Cobol ...
fate worse than death. No wonder there are so many conservatives
at large ... anyone whose job that is can't be liberal after a
few grueling years.

On the upside, they will make shitloads of money.
On the downside, those costs will be passed on to YOU,
o dear consumer.

I remember JCL. God, what fun.

Eugene A. Pallat

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

Maryse Turcotte <maryse....@sympatico.ca> wrote in article
<334F0C...@sympatico.ca>...

> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course
that
> it must have been a way to economize on storage and time of execution
which
> I heard was very costly back then... Still, I find it hard to believe
> that they didn't anticipate the problem which wasn't that far away...

I did work for a government agency that used ONE digit years with the
excuse that "No program / project lasted more than 10 years."

Then the exceptions. For this year, you have to check this other field and
if it's so and so, it's that year. And if it's that value, it's another
year, ad nauseum.

They wasted 20 to 30 times as much space figuring out what they actually
had compared to using 4 digit years in the first place.

And believe me, that was the least of the probems with their programs.

Clive D.W. Feather

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
<eapa...@orion.data.com> writes

>The problem is far worse that you people can even imagine. There are
>already people who have had credit card purchases rejected because the
>expiration date of "00" interprets to 1900 - ergo expired card.

Or even 12/99 - see my posting to comp.risks a month or two ago.

>Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>Turn it back on after 10 minutes and see what happens. Most of them will
>have a problem.

If it lets you set that date and time, you've already got problems.

--
Clive D.W. Feather | Director of Software Development | Home email:
Tel: +44 181 371 1138 | Demon Internet Ltd. | <cl...@davros.org>
Fax: +44 181 371 1037 | <cl...@demon.net> | Abuse:
Written on my laptop; please observe the Reply-To address | <cl...@bofh.org>

Clive D.W. Feather

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <33553d1d....@news.sci.fi>, =?iso-
8859-1?q?Paul_Kein=E4nen?= <kein...@sci.fi> writes

>I did not know that you have credit cards that are valid for many
>years, but anyway, there is an easy solution to this problem. All
>cards issued before the year 2000 should have a validity date of Dec
>31, 1999 (or earlier). New cards are delivered to all customers in
>December 1999 and the new cards are valid _starting_ from Jan 1, 2000
>and valid until any convenient date in year 200x.

Sheesh !

To add to all the other hassles, you want to multiply the workload of
the renewals department by 36 ? [or 24 or 48, depending on your bank]

DaveHatunen

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <01bc46d2$5a0402a0$30a036cf@alpha>,
Eugene A. Pallat <eapa...@orion.data.com> wrote:

[...]

>Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>Turn it back on after 10 minutes and see what happens. Most of them will

>have a problem. Supposedly NT can survive.

You mean it won't go to 12/22/99?

--
*********** DAVE HATUNEN (hat...@netcom.com) ***********
* In the land of the blind, the one-eyed man is king... *
* Until they find out he can see, then they kill him *
*********************************************************


Peter de Jager

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <334f01fe...@news.mindspring.com>,

bglas...@earthling.net (Bruce Glassford) wrote:
let's see how many programmers
> caught the fact there's no February 29, 2000. (me being lazy, looked
> up my old date calculation routine - it will work for 2000, but failed
> for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
> in the leap year if divided by 100 and the non-leap year if divided by
> 400 routine)
> ... Bruce


Sigh.... here we go again...

There is a Feb 29th 2000

The rule is... if it's evenly divisible by 4 it's a leap year...
unless it's evenly divisible by 100 in which case it isn't
unless it's ALSO evenly divisible by 400 in which case it is

Sigh...

Please... pull out the encylopedia Britannica
Look under Gregorian calendar

sigh...

And we think we're capable of solving the Year 2000 problem when we
can't even figure out the leap year rule... ????

Peter de Jager

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <5iob49$n...@lal.interserv.com>, James...@CIS.CompuServe.com
(James M. Curran) wrote:


ahem... consider the following please...

The end date of a mortgage had to handle the century rollover because
in 1970 a 30 yr mortgage would already have an end dat there... so the
programmer wrote the program to accomdate the situation...

However... the START date of the mortgage in 1970 did NOT have to
handle 2000+ and there they typically only used a 2 digit date for 'start
dates'...

The beauty about this little problem... is that we'll very soon be able
to see who was wrong about this issue... the weird thing is that I hope I
am.

Roy Dent

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In message <334f01fe...@news.mindspring.com>bglas...@earthling.net, bglas...@earthling.net said:
> ==========
> alt.folklore.urban #91, 2338 chars, Apr 12 03:34 97
> From: bglas...@earthling.net,
> ----------
> Article: 263388 of alt.folklore.urban
> Xref: cix.compulink.co.uk rec.org.mensa:160615 sci.math:132384 sci.misc:18
> 917 sci.skeptic:208918 comp.misc:25333 alt.folklore.computers:119244 alt
> science:33635 alt.folklore.urban:263388
> Path: cix.compulink.co.uk!betanews.compulink.co.uk!dispatch.news.demon.net
> !demon!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.c
> ndspring.com!usenet
> From: bglas...@earthling.net (Bruce Glassford)
> Newsgroups: rec.org.mensa,sci.math,sci.misc,sci.skeptic,comp.misc,alt.folk
> Subject: Re: 2000 and the computer
> Date: Sat, 12 Apr 1997 03:34:51 GMT
> Organization: MindSpring Enterprises
> Message-ID: <334f01fe...@news.mindspring.com>
> References: <19970410182...@ladder01.news.aol.com> <5ikkij$g9f$4@
> NNTP-Posting-Host: ip137.washington6.dc.pub-ip.psi.net
> X-Server-Date: 12 Apr 1997 03:35:14 GMT
> X-Newsreader: Forte Free Agent 1.1/32.230
> Lines: 28

>
>
> On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
> wrote:
>
>> bill...@aol.com (BillH1108) wrote:
> <snip>
>>
>> More generally, the image presented of a vast blinking-out of everything
>> computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
>> far-fetched. Certainly a number of unexpected glitches will occur from
>> computers on autopilot, but we expect most major systems will be the
>> objects of at least some experimentation before 2000, during which time
>> the likely problems will be discovered.
>>
> <snip> An interesting discussion arose at lunch today about the Y2K
> problem (hey, we're all in the computing/management consulting business -
> why talk about something interesting?). Someone made the point that he
> didn't want to rely on any imbedded system on January 1, 2000, but didn't
> worry about financial systems until December 31, 2000, when they'll all
> go crazy trying to do year end. Also, there will be an interesting test
> on March 1, 2000 - let's see how many programmers caught the fact there's

> no February 29, 2000. (me being lazy, looked up my old date calculation
> routine - it will work for 2000, but failed for 1900. Sloppiness here
> equals extreme accuracy :-) - forgot to put in the leap year if divided
> by 100 and the non-leap year if divided by 400 routine) ... Bruce
>

Oh boy, have you got a *problem* Bruce!

I may not be a hot computing/management bod, but I can read and divide
2000 by 400 in my head without computer assistance. You _really_ should
be able to locate this kind of information for yourself but, as you seem
unable, let me quote this from Whitaker's Almanac which sums things up
pretty concisely:

" A year is a leap year if the date of the year is divisible by four
without remainder, unless it is the _last_ (my emphasis) year of the
century. The last year of a century is a leap year only if its number is
divisible by 400 without remainder, e.g. the years 1800 and 1900 had only
365 days but the year 2000 will have 366 days. "

Check it out for yourself, unless you care to wait until Tuesday 29th
February 2000 comes around!

Adn yes, did you notice that the year 2000 is the _last_ year of this
century?

Cheers,

Roy


Dene Bebbington

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

Don McKenzie <mc...@wavnet.com> wrote:
>In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
><eapa...@orion.data.com> wrote:
>
>[snip]

>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> Turn it back on after 10 minutes and see what happens. Most of them will
>> have a problem. Supposedly NT can survive.
>>
>Or use a Mac. No problem.

That's because the Mac OS wasn't written by Microsoft!!

--
Dene Bebbington

"I mean, who would have noticed | "It is impossible to enjoy idling
another madman around here?!" | thoroughly unless one has plenty
- Blackadder | of work to do." - Jerome K Jerome

Mark Zavislan

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

Eugene A. Pallat wrote:

>
> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
> Turn it back on after 10 minutes and see what happens. Most of them will
> have a problem. Supposedly NT can survive.
>

My PC came back with 12/22/99 00:05. No problem.

Mark "what's ten days among friends" Zavislan
--
* Mark A. Zavislan * I don't give them hell, *
* zavi...@lr.net * I just tell the truth and *
* * and they think it is hell - Truman *

Robert Billing

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <334F3E6D...@transbay.net> ec...@transbay.net "ecsd" writes:

> I remember JCL. God, what fun.

Remember it? I've still got the manual...

--
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/
"might there be some celestial tribunal at which a crafty advocate
could get a sinner off hell? ...my heart sank at the thought of
eternal work before a jury of prejudiced saints."

Brett Frankenberger

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <SSnrxrAU...@bebbo.demon.co.uk>,

Dene Bebbington <de...@bebbo.demon.co.uk> wrote:
>Don McKenzie <mc...@wavnet.com> wrote:
>>In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
>><eapa...@orion.data.com> wrote:
>>
>>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>>> Turn it back on after 10 minutes and see what happens. Most of them will
>>> have a problem. Supposedly NT can survive.

DOS/Windows/NT/etc. will all survive. That will also all show the
incorrect date if the PC is vulnerable to this problem. It is not
related to the OS. (Also, YM 23:55, not 24:55).

>>Or use a Mac. No problem.
>
>That's because the Mac OS wasn't written by Microsoft!!

As much as it pains me to defend Bill, this isn't a Microsoft issue.
NT, Win95, and even DOS, handle Y2K just fine. Notice that the above
procedure requires that your PC be *powered off* at 00:00 on 1/1/00.
That's because if it on, DOS, Windows, NT, 95, whatever, will handle it
just fine -- they maintain a perfectly viable clock. The problem is
with the hardware clock on the PC, which keeps time in between reboots
and power-cycles.

It, in many cases, cannot deal with Y2K correctly. AFAIK, Bill neither
designs CMOS clocks nor writes BIOSs ... so it's not a case of
Microsoft writing non-Y2K code.

Brett Frankenberger

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

In article <33513E...@mail1.lr.net>,
Mark Zavislan <zavi...@mail1.lr.net> wrote:

>Eugene A. Pallat wrote:
>
>>
>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>
>My PC came back with 12/22/99 00:05. No problem.

Did you actually try it?

Brett "25:05" Frankenberger

Bob Casanova

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

On Sun, 13 Apr 1997 14:23:55 GMT, hat...@netcom.com (DaveHatunen)
wrote:

>
>In article <01bc46d2$5a0402a0$30a036cf@alpha>,
>Eugene A. Pallat <eapa...@orion.data.com> wrote:
>

>[...]


>
>>Try setting the date and time on your PC to 12/21/99 24:55 and power off.

>>Turn it back on after 10 minutes and see what happens. Most of them will
>>have a problem. Supposedly NT can survive.
>

>You mean it won't go to 12/22/99?

From 24:55?

;-)

Bob Casanova

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to

On Sun, 13 Apr 1997 16:14:32 -0400, Mark Zavislan
<zavi...@mail1.lr.net> wrote:

>Eugene A. Pallat wrote:
>
>>
>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> Turn it back on after 10 minutes and see what happens. Most of them will
>> have a problem. Supposedly NT can survive.
>>
>

>My PC came back with 12/22/99 00:05. No problem.

Just to satisfy my curiosity, how'd you set the time to 24:55 without
an error?

"What's an extra hour in the day between friends?"

;-)

Jay R. Ashworth

unread,
Apr 13, 1997, 3:00:00 AM4/13/97
to