Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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 <dave_sc@csl.sri.com> 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 <leot@iphase.com>)
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.
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.]
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/>
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/
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 <mercuri@acm.org>
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 <msb@vex.net>
[Mark likes PGN's old RISKS quote:
"This problem gives new meaning to "going out on a date"]
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
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]
> We would not survive the loss of our data center. Common sense might suggest backing up your data. Off campus.
Please report problems with the web pages to the maintainer