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 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" 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 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 ) 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" 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 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? ------------------------------ Date: Sat, 1 Jan 2000 04:29:45 +0000 From: Matt 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 ;) matt@redcat.org.uk - - --> http://www.redcat.org.uk/~matt/ ------------------------------ Date: Sat, 1 Jan 2000 23:33:19 -0500 (EST) From: Rebecca Mercuri 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 ------------------------------ Date: Sat, 1 Jan 2000 16:22:49 -0500 (EST) From: msb@vex.net (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 . Mark Brader, Toronto [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 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, jepstein@acm.org ------------------------------ Date: 23 Dec 1999 11:33:40 -0600 From: John Palkovic 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 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: RISKS-request@csl.sri.com 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 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 (Dennis Rears). .UK users should contact . => 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 risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]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 ************************