The RISKS Digest
Volume 20 Issue 72

Sunday, 2nd January 2000

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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…


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

Y2K early reports

"Peter G. Neumann" <>
Sun, 2 Jan 100 12:45:47 PST
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
claims a date of "Saturday, January 1, 100".

Also  [That's some old chicken!]

Also an ELM 2.4 problem (noted by Leo Taiariol <>)

On 2 Jan, gave Sunday, 2 January 100
    Error:  cannot open /ht/tv/schedules/January-1-19100

[Dave sent me this at Fri, 31 Dec 1999 19:39:43 -0800:]
GO to 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
    ["Look mom I hacked dea.comm!!! y2k crew is here.  hacked by miloco.]

There is some lovely Y2K humor on .

On 2 Jan,
  (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;
    year += 2000;
  return(this_month[month]+" "+day+", "+year);
// -->

The flaw is beautifully obvious.  The comment is wonderful.
  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,
gave the date as
      3 Jan, 3900
and gave 01/2/20100
  claims a Sonic Youth CD will be made available 10 Oct 2011.

Thanks to Dave.  Also his colleague Mike Hogsett noted that
shows the next Star Trek Voyager episode has a first air-date of 1/1/1900.
Mike also noted that 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.

Pentagon satellite intelligence system Y2K failure

"Peter G. Neumann" <>
Sun, 2 Jan 100 10:13:12 PST
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.]

Re: Y2K

Derek Tam <>
Sun, 02 Jan 2000 14:48:01 -0500
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?  <>

Re: Y2K goofs

Matt <>
Sat, 1 Jan 2000 04:29:45 +0000
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" - 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 ;)      -   - -->

Y2K Risks Comment

Rebecca Mercuri <>
Sat, 1 Jan 2000 23:33:19 -0500 (EST)
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 <>

Y2K kills Toronto bus information service

Mark Brader <>
Sat, 1 Jan 2000 16:22:49 -0500 (EST)
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"]

Y2K warning software is wrong!

Jeremy Epstein <>
Sun, 2 Jan 2000 07:15:30 -0500 (EST)
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,

Re: Y2K fear vs. Common sense (RISKS-20.70)

John Palkovic <>
23 Dec 1999 11:33:40 -0600
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.

  [Also commented on by Mike Ellims.  PGN]

Re: Y2K fear vs. Common sense (RISKS-20.70)

William Ehrich <>
Mon, 20 Dec 1999 13:25:45 -0600
> 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