Cheeky would be very unhappy to see his guru debunked.
Westergaard Year 2000
April 27, 1999
Unbelievable: Misinformation about The Dreaded Nines
By E.L. Core
(http://www.y2ktimebomb.com/Computech/Issues/lcore9917.htm)
Computers are complicated. So, information about computers is
complicated. And misinformation about computers is complicated and,
unfortunately, widespread.
I have already written at length about the alleged "Nines Problem" --
that problems will occur when processing data for April 9, 1999, and
September 9, 1999 -- in two articles: The Dreaded Nines: Will They Be
So Bad? [http://www.y2ktimebomb.com/Computech/Issues/lcore9846.htm]
and More on The Dreaded Nines and Other Proverbial Dates
[http://www.y2ktimebomb.com/Computech/Issues/lcore9850.htm]. (If you
are unfamiliar with this topic, I strongly urge you to read those
articles if you want to continue reading here.) I also wrote about
them briefly at the conclusion of NERC's April 9 Y2K Drill: What It
Is, And What It Is Not
[http://www.y2ktimebomb.com/Industry/Utilities/lcore9914.htm].
But, on April 20, I came across a tortured mishmash of misinformation
on the "Nines Problem" that I want to examine in detail. It is in the
form of question-and-answer. My comments are interspersed between the
quoted sections that follow.
"Question: Some questions from my employees concern the date 9-9-99.
Is there any concern for this date rolling over to all zeroes on
systems? -- John"
That question, in one form or another, is unfortunately quite common.
As I have pointed out, 4-9-99 and 9-9-99 have been Y2K Red Herrings:
"In one way or another, Y2K Alarmists have trumpeted those days as
harbingers of the computer problems to come in 2000. Though each day,
in its own way, may have relatively minor data-processing problems,
their connection with Y2K is tenuous" (Don't Chase the Y2K Red
Herrings [http://www.y2ktimebomb.com/Media/lcore9915.htm]).
"Answer: Sept. 9, 1999, is one of two dates thought to be susceptible
to what is known as the 'Nines Problem.' When programmers writing
applications want to signify an 'end-of-file' or 'end-of-process'
command -- in other words, a condition that tells the computer 'if you
see this date, you can stop' -- some used a date with four nines in a
row, or '9999'...."
The "nines" situation posited here does not involve merely four nines
in a row as a trigger, but the appropriate number of nines in a row.
If the data field in question allowed a maximum of three digits -- for
current age, say -- then three nines would be the trigger (but only if
the software was programmed accordingly). In a six-digit date field,
then, the appropriate number of nines would be six, not four; in a
five-digit date field, it would be five nines in a row.
"April 9, which recently passed without any errors making their way
into the public eye, is the 99th day of the year. If a programmer used
the Julian calendar -- which most folks stopped using when Pope
Gregory introduced his innovations about 400 years ago -- there is the
possibility that they could inadvertently trigger the end-of-file
process."
My jaw dropped when I first read that paragraph. When programmers
speak of Julian dates, they are not talking about the Julian calendar,
but about a certain format in which dates are sometimes stored. (I
have explained this format in The Dreaded Nines.) I have no idea why
dates stored in that fashion are called Julian dates, but it
apparently comes from IBM usage. Dr. J. R. Stockton has called it "a
most unfortunate piece of nomenclature"; see his discussion of Our
Calendars [http://www.merlyn.demon.co.uk/miscdate.htm#Cals]. The
question-and-answer author explains storage of Julian dates correctly
-- well, almost -- in the next paragraph.
"The Julian calendar would produce a '9999' date only if it was
misformatted DDDYY, which would be '09999' on April 9. Correctly
formatted (YYDDD), however, April 9 would appear as '99099'...."
Storing a Julian date in "DDDYY" format is not a misformatting.
Sometimes, it is not only legitimate but advantageous to keep Julian
dates in that fashion, such as for a report that compares sales on a
given date with sales on the same date in the previous year.
"In the Gregorian calendar, Sept. 9 is '990909,' not '9999.' No matter
how badly mangled the Gregorian date format, it never produces
'9999'...."
September 9, 1999, is "990909" ("YYMMDD" format) or "090999" ("DDMMYY"
format). Julian calendar, Gregorian calendar, no matter.
"Presumably, if programmers decided to use a Julian calendar, they
would be aware of the potential problem with the string of four nines
when selecting an end-of-file command. Given the total absence of
reports of major system errors on April 9, almost all programmers did
avoid the series of mistakes that would have caused a problem."
I shudder. True, there were no reports of major (any?) data-processing
problems associated with April 9, 1999. But the explanation given here
is just nonsense. As I explained above, storing a Julian date as
"DDDYY" (which would make "09999" the Julian date of April 9, 1999) is
not a mistake. Nor is the posited trigger a series of four nines: it
is a series of all nines, and "09999" is not all nines.
"For the problem to kick in on Sept. 9, programmers would have had to
make even more mistakes while writing their software -- they would
have had to misformat the date in a way that defies logic." As if
programmers are incapable of defying logic.
Seriously, I have already explained at length in More on The Dreaded
Nines that data-processing problems may be associated with September
9, 1999 -- but not primarily because programmers have coded the
software poorly (though that may be true in some cases) nor for other
technical reasons which are not out of the question. Rather, because
users have decided on their own to pick certain dates and attach
special meanings to them -- one of those dates being September 9,
1999.
[BTW, "other technical reasons which are not out of the question" is
an allusion to the lack of EOF detection on older machines.]
"The Nines Problem is almost totally a myth, except for misformatted
Julian dates. And that critical date has already passed."
Hardly. Indeed, as I explained in More on The Dreaded Nines, the
argument for data-processing problems associated with September 9,
1999, has always been much better than that for April 9, 1999. Not
that I'm predicting major problems for 9/9/1999, mind you: I am
certainly not doing that. I'm just pointing out that the possibility
exists, however unlikely.
It would have been bad enough had such a question-and-answer article
-- such a mishmash of inaccuracies and outright errors -- come from,
say, a pastor trying to explain the "Nines Problem" to the readers of
his newsletter. Or from the director of a non-profit organization
trying to explain it to his staff. Or from a journalist trying to
explain it to the readers of a small-town newspaper. It would have
been bad enough -- but excusable. After all, computers are
complicated.
What would you say, though, if you knew that it came, not from a
reporter nor from a bureaucrat nor from a clergyman, but from the
"editorial director of Ziff-Davis' ZDY2K Web site and president of
Internet/Media Strategies Inc., a Lakewood, Wash.-based consulting
company" in an article "Special to ABCNEWS.com"?
Here it is, folks: No Revolution No. 9: Julian or Gregorian, Calendars
Avoid 9999
[http://www.abcnews.go.com/sections/tech/Y2KReady/y2kready990419.html].
Yes, what would you say? The first word that came to my mind was
"appalling". A week later it's still the word that comes to my mind. |
