precedence: bulk
Subject: Risks Digest 20.72

RISKS-LIST: Risks-Forum Digest  Sunday 2 January 2000  Volume 20 : Issue 72

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.72.html>
and by anonymous ftp at ftp.sri.com, cd risks .

 Contents:
Y2K early reports (PGN)
Pentagon satellite intelligence system Y2K failure (PGN)
Re: Y2K (Derek Tam)
Re: Y2K goofs (matt)
Y2K risks comment (Rebecca Mercuri)
Y2K kills Toronto bus information service (Mark Brader)
Y2K warning software is wrong! (Jeremy Epstein)
Re: Y2K fear vs. Common sense (John Palkovic, William Ehrich)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Sun, 2 Jan 100 12:45:47 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Y2K early reports

On the whole, Y2K came and went without major immediately noted problems.
Predictions still abound for deferred problems.  In this message, I have
attempted to summarize in one place some of the reported Y2K weirdnesses.

There are a lot of lessons that should have been learned from the entire
process, but we'll address those in this forum later on after a little more
time to reflect.  My preliminary conclusions are not surprising: there has
been a pervasive lack of foresight, generally lousy software engineering,
overemphasis on the remediation process without deeper understanding,
ignoring the risks of remediation by potentially untrustworthy third
parties, and so on.

Dave Stringer-Calvert <[email protected]> has been monitoring CSL's
Y2K compliance.  I have adapted the following items from his e-mail to me:

 [PLEASE note the Date: field on this message.  This is apparently a
 widespread problem.  In my case, it seems to be a lurking Y2K
 noncompliance in the Columbia MM that I have been using for so many years.]

QuidProQuo 2.1.2 web servers for Macs are returning 1-Jan-100 as the date
to client queries...

Dave's favorite "The Yorkshire Evening Press" at http://www.thisisyork.co.uk
claims a date of "Saturday, January 1, 100".

Also http://www.kfrc.com/  [That's some old chicken!]

Also an ELM 2.4 problem (noted by Leo Taiariol <[email protected]>)

On 2 Jan, www.cowsnet.com/home.html gave Sunday, 2 January 100

www.kpix.com/tv/schedule.html
 gives:
   Error:  cannot open /ht/tv/schedules/January-1-19100

[Dave sent me this at Fri, 31 Dec 1999 19:39:43 -0800:]
GO to www.npl.co.uk/cgi-bin/countdown.pl NOW!!!!
It reads "31 Dec 1999 26:39 UTC"
   [Not only an incorrect atomic clock, but WRONGLY incorrect!
     18:39 PST + 8:00 time shift = 27:39, not 26:39 UTC!
   [It has now been repaired.  PGN]

Various sites have been hacked, including
 www.dea.com
   ["Look mom I hacked dea.comm!!! y2k crew is here.  hacked by miloco.]
 www.core.net

There is some lovely Y2K humor on www.2600.com .

On 2 Jan, http://www.giga-byte.com/gigabyte-web/newindex.htm
 (they manufacture motherboards) has the date as Jan 2 2100.
The javascript function is:

// standard date display function with y2k compatibility

function displayDate() {
 var this_month = new makeArray(12);
   this_month[0]  = "January";
   this_month[1]  = "February";
   this_month[2]  = "March";
   this_month[3]  = "April";
   this_month[4]  = "May";
   this_month[5]  = "June";
   this_month[6]  = "July";
   this_month[7]  = "August";
   this_month[8]  = "September";
   this_month[9]  = "October";
   this_month[10] = "November";
   this_month[11] = "December";
 var today = new Date();
 var day   = today.getDate();
 var month = today.getMonth();
 var year  = today.getYear();
 if (year < 100){
   year += 1900;
 }
 else{
   year += 2000;
 }
 return(this_month[month]+" "+day+", "+year);
}
// -->

The flaw is beautifully obvious.  The comment is wonderful.

http://www.wfs.org/futurist.htm
 Time left to January 1 2000:
 -1 years, 11 months, 29 days, 14 hours, 21 minutes, 45 seconds
and counting...  It's actually correct, in a strange sort of way.

 [Jeremy Epstein has another manifestation of this problem, below.  PGN]

On 2 Jan, the Australian online media news gateway www.pressrelease.com.au,
gave the date as
     3 Jan, 3900
and www.happypuppy.com gave 01/2/20100

http://www.amazon.co.uk/exec/obidos/ASIN/B00002716Z/qid=946835401/sr=1-6/026-4578278-4117058
 claims a Sonic Youth CD will be made available 10 Oct 2011.

Thanks to Dave.  Also his colleague Mike Hogsett noted that
 http://www.startrekcontinuum.com/brf/VOYUpcomingtop.asp
shows the next Star Trek Voyager episode has a first air-date of 1/1/1900.
Mike also noted that www.abc7news.com had Jan 1 100.

John Murrell observed the US Naval Observatory calendar at 19,000.

Andrew Koenig spotted the New York Times Website, January 1, 1900.

------------------------------

Date: Sun, 2 Jan 100 10:13:12 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Pentagon satellite intelligence system Y2K failure

As the Pentagon folks were claiming that everything was working fine, a
computer system processing satellite intelligence data lost its data
collection ability at 7pm EST (midnight GMT) on Friday evening for about 2.5
hours.  [Source: Pentagon Withheld News of Major New Year's Computer
Failure, by Roberto Suro, *The Washington Post*, 2 Jan 2000, A8.]

------------------------------

Date: Sun, 02 Jan 2000 14:48:01 -0500
From: Derek Tam <[email protected]>
Subject: Re: Y2K

I'm sure someone else will have pointed out the cause of this problem by
now, I had a first hand experience with it.  Script-generated dates using
the localtime() function return a list of values, the current month, day,
hour, minutes, seconds, and year.  A common misconception is that the
(former) 2-digit year value is just that: a 2-digit year, when in fact it is
the number of years elapsed since 1900.  So when we hit Jan 1, 2000, the
year value became 100.  So now were are seeing some fairly interesting dates
such as Jan 1, 100 and Jan 1, 19100 (or 20100) for those who were prepending
the "19" to the year value.  The correct way to resolve this is of course
$year = 1900 + $year.

Derek Tam      Skwid?  <http://www.derekweb.com/>

------------------------------

Date: Sat, 1 Jan 2000 04:29:45 +0000
From: Matt <[email protected]>
Subject: Re: Y2K goofs

Just a few goofs I spotted on the graveyard shift today.

Many little websites - localtime error, pretty common, where someone
had misunderstood the value returned (current year, minus 1900)
and assumed it meant "2 digit year". Prefix it with 19 and we get
"current date: January 1, 19100"

www.apple.com - localtime error, by someone who at the stroke of midnight
GMT conveniently updated their code to change the prefix from "19" to "20"
having presumably audited their code. Ooops.

The claim on their main page over their very prominent Y2K statement that
the date was "January 1, 20100"

Compaqs site somehow managed to claim it was January the 2nd.

Sun's "Y2K readiness countdown" told me the time was "0-6:53:23 January 1
2000" although I suspect this may be a seriously broken effort at converting
their value (american somewhere) to my localtime (GMT). This was viewed on a
sun, using netscape. The time at that point was just gone midnight.

And you already know about the Auckland airports fantastic 100AD jumbo. I
have to wonder if the civil aviation authority permits 1900 year old
aircraft to make such long flights. ;)

The risk being highlighted? well, a large number of these problems are
simply firms making themselves look stupid in their rush to highlight how
Y2K aware they are.

Here?  Well, I can't tell you where "here" is, but we had a serious
alert level raised at one point... for a dead fuse.

The fireworks were nice ;)

[email protected]      -   - --> http://www.redcat.org.uk/~matt/

------------------------------

Date: Sat, 1 Jan 2000 23:33:19 -0500 (EST)
From: Rebecca Mercuri <[email protected]>
Subject: Y2K Risks Comment

Since the world's computers didn't all crash on 1/1/00, some newscasters
have needed to find a way to share their angst with the public.  Today I
heard a reporter complain about the $XB "wasted" on solving the Y2K bug,
with the speculation that it was a ploy by the computer industry to get
extra income.  I wonder if we spent $NB on preventive health care and nobody
got sick, if the news media would consider that also a waste?

As for myself, all of the billing systems I'd authored back in the early
1980s that weren't Y2K compliant were thankfully retired by 1998 (still a
lot longer than I'd expected they'd continue to have been used).  I did get
a call at 11:30AM (EST) from an old client with an old 486PC that seemed to
have reset its date to January 4, 1980. After using the Date command with
01-01-2000 everything seemed to be fine. (No, I didn't charge them.)

A Happy (and Profitable) Y2K to All,  Rebecca Mercuri <[email protected]>

------------------------------

Date: Sat, 1 Jan 2000 16:22:49 -0500 (EST)
From: [email protected] (Mark Brader)
Subject: Y2K kills Toronto bus information service

It was possible from 1987 to 1999 to phone a number posted on each bus
stop in Toronto and hear the scheduled time of the next two or three buses.
The TTC determined some months ago that this system was not Y2K compatible
and was also under-used; so as of today, it's been withdrawn indefinitely.
See <http://www.ttc.ca/postings/gso-comrpt/documents/report/f591/_conv.htm>.

Mark Brader, Toronto <[email protected]>
  [Mark likes PGN's old RISKS quote:
    "This problem gives new meaning to "going out on a date"]

------------------------------

Date: Sun, 2 Jan 2000 07:15:30 -0500 (EST)
From: Jeremy Epstein <[email protected]>
Subject: Y2K warning software is wrong!

I run McAfee Office 2000 on my home computer, which includes McAfee WinGauge.
That's a little gizmo with four panels: the CPU usage, memory usage, DOS
memory usage, and "days to Y2K".  This morning (January 2nd), the days
to Y2K reads "1", which I suppose is correct in an unusual sense of the
term.  But the time remaining to Y2K is -7:-18:-55 as I write this.  While
I'll agree that January 1st ended about 7 hours and 20 minutes ago, I
wouldn't normally expect to see that written as -7:-18:-55!

Of course, this isn't mission critical, but it is a rather strange symptom
for software that's supposed to be providing a countdown...

--Jeremy Epstein, [email protected]

------------------------------

Date: 23 Dec 1999 11:33:40 -0600
From: John Palkovic <[email protected]>
Subject: Re: Y2K fear vs. Common sense (RISKS-20.70)

Ironic that "Common sense" is mentioned in the subject of this message.

I think someone has been watching too many Hollywood movies. Fuel in tanks
does not explode spontaneously; it needs to be mixed with a greater volume
of air and ignited. This is a continuous process in a gasoline motor. Fuel
tanks can burn, but they don't explode too well (excepting Ford Pintos).

The risk here is that someone has not checked their facts and is spreading
fear and panic. It seems that in the case of Y2K, the greatest thing we have
to fear is fear itself.

-John
 [Also commented on by Mike Ellims.  PGN]

------------------------------

Date: Mon, 20 Dec 1999 13:25:45 -0600
From: William Ehrich <[email protected]>
Subject: Re: Y2K fear vs. Common sense (RISKS-20.70)

> We would not survive the loss of our data center.

Common sense might suggest backing up your data. Off campus.

------------------------------

Date: 13 Dec 1999 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
.MIL users should contact <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
  [volume-summary issues are in risks-*.00]
  [back volumes have their own subdirectories, e.g., "cd 19" for volume 19]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
Also, new AUSTRALIAN archive http://mirror.aarnet.edu.au/risks/
PostScript copy of PGN's comprehensive historical summary of one liners:
  illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.72
************************