Die hier angebotenen Informationen haben wir mit freundlicher Genehmigung aus
den Beiträgen im Risk-Forum (comp.risks) zusammengestellt. Vorerst alles
in 
englischer Sprache.
Bitte beachten Sie die Hinweise am Ende dieser Seite.
Amidst all the hoopla over Y2K, we have much to contemplate. There is a big lesson to learn from it about our dependency on technology. For all the advances in capability we have made (including those that make possible the distribution of these words), we have created systemic risks. Under evolution organisms adapt (slowly!) to their environment. Technology represents the opposite approach: humans attempting to adapt their environment to themselves, in their current state. Each step of "technolution" solves or eases some existing problem, but may change the overall landscape. In the last couple of centuries, the pace has accelerated, and luxuries became conveniences became necessities. Our senses developed to a good level of acuity over the millenia, now they are often necessarily aided by external devices. Our brains have large, unused capacities, but we rely on easily lost electronic notepads instead of our memories. Cars take us from one place to another through suburbs spread beyond walkable distances, fouling the air along the way. Many people have trouble walking any distance at all (which problem can be made worse by having to carry a heavy external "brain", which can also be lost or stolen). Essential knowledge is placed on a worldwide network, which must work all the time. Food comes from all over the world, as does the energy to move us and our goods, and change the temperature of our surroundings (intentionally or otherwise). Now human reproduction is becoming more technological. It is a very complex system which we take for granted. The very minor problem of Y2K was sufficiently widespread to threaten to disrupt much or all of this. But Y2K was relatively easy to anticipate and head off. Something else might not be. Recent news stories have appeared about the President proposing defenses against cyber-terrorism and a lowered redundancy and reliability in the deregulated national power grid. The survivalists now have to figure out what to do with their provisions, but every-man-for-himself is not the right way to back up this system. Do we have the vision to reap the benefits of technology and avoid the pitfalls or will we change our environment beyond our ability to adapt to it fast enough ? As the now ancient margarine commercial reminded us, "It's not nice to fool Mother Nature".
Thousands of newborn babies have been listed officially as 100 years old. Computers at English register offices are refusing to recognise the year as 2000 and are printing 1900 on birth certificates. [...] [Source: The (London) *Times*, 17 Jan 2000; The full story is online at: http://www.the-times.co.uk/news/pages/Times/frontpage.html?1069542] Brian Randell, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK +44 191 222 7923 http://www.cs.ncl.ac.uk/~brian.randell/
A popular free-of-charge predictor for UNIX platforms, SatTrack V3.1,
went completely haywire.
On 7 Jan. it told me:
Date: XXX -358Jan01 (I think the XXX should be the day of the week)
UTC : -358-11:-32:-94
Countdown to next pass: 657443 days 11 hours 32 minutes 10 seconds
(this is rather precisely 1800 years)
Satellite position: 0.0 deg lat. 0.0 deg. long. (does not move)
In all fairness, this version is a few years old; the latest version
comes at a cost, and is said to be Y2K compliant.
Another popular program, WinOrbit 3.5 for Windows 95/98 nearly got it right.
I found only one problem:
If you want to print the prediction for several future passes, you get a
pop-up on which you have to enter the starting time for the calculation.
There is a "NOW" button that fills in this entry, giving the year as 00.
00 means 1900 to the program.
You can type 2000 instead of 00, and you get the correct results.
Easy, once you know. But it took some time to first discover that the
results were wrong, then figure out the work-around.
I am told that yet another predictor works fine in 2000, as long as you use
the orbit parameters, the so-called "2-line elements", from end 1999, but
goes wrong with parameters that have a year entry of 00. I haven't got the
details.
Erling Kristiansen
I managed to get Microsoft Flight Sim 2000 Pro Edition for Xmas, great! After installing I went to the Microsoft web site and found an update - of course there was one - 9 megabytes in total. I downloaded it, installed it, everything was fine. A few days later I did my in-frequent disk cleanups, etc. I had not run scandisk for ages so set it off. I was surprised when it announced that it had found a bad file. The file was with one of the Flight Sim 2000 files, and the problem was that it had an invalid date. This problem occurred with all the Flight Sim 2000 files that had come as part of the update I had downloaded. Was it a Y2K problem? I'm not sure. Everything worked okay and McAfee Virus Checker didn't complain about funny dates on the files. Of course, it could have been a problem with the disk scan program. Dave Smith
There has been heated debate in the Berlin newspapers about the fire department's computer problems over New Year's. It seems that just after midnight the dispatching systems broke, but they broke in an unexpected way: they told the dispatchers that an alarm had been given to a fire station, when in reality the fire station did not receive the alarm, and kept playing cards and wondering why there were no fires this nice New Year's Eve. [This is in itself a very hard to avoid security risk.] At one point an exasperated police car drove to a fire station, which was just around the corner to ask if they needed an engraved invitation or what?! The systems also logged fire engines as being somewhere in use when they were actually sitting in the fire house, and thus tried to alarm fire engines that were further away from the fire. There has been lots of finger-pointing. The systems were "Y2K-secure" because they were tested for this 2 weeks ago. [Gosh, I didn't realize that someone had found out how to prove by test that software functions properly! -dww] The chief fire fighter had to be called in at about 1.30 am to figure out what to do, eventually falling back on very old equipment: people, paper and pencil. The blame has been put on the massive number of calls to the fire department during the night, which had overloaded the system. Maybe I ought to invest in a second fire extinguisher... Some on-line articles: http://www.BerlinOnline.de/wissen/berliner_zeitung/archiv/2000/0103/lokales/0064/index.html http://www.tagesspiegel.de/archiv/2000/01/04/ak-be-kr-13983.html http://www.tagesspiegel.de/archiv/2000/01/06/ak-be-st-24269.html Interesting too the article in August 1999 http://www.tagesspiegel.de/archiv/1999/08/05/ak-be-st-23279.html where an official says that the fire department is just spreading panic by saying that they will be having problems on New Year's Eve... Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin weberwu@tfh-berlin.de, http://www.tfh-berlin.de/~weberwu/
The Kremlin press office's computer communication system was victimized by Y2K, blocking their ability to send e-mail. Reportedly, they will have the problem fixed by ``the end of the month''. [Source: Agence France Presse, 13 Jan 2000] Greg Lastowka, University of Virginia Law School lastowka@virginia.edu http://hobbes.itc.virginia.edu/~fgl2q/home.html
Newsgroups: alt.fan.cecil-adams "Wulfdog" <johnw@icok.net> excerpt: >I turned on a 286 PC in my office today. I looked at the date and it said >Jan 05 2000. Previously I had ran the date forward on my new HP and it went >to 2099 and rolled back to 1980. I quickly ran the 286 date up and to my >surprise it went to 2099 and rolled back to 1980. I wonder what those >little diskettes with the Y2K test were actually checking for, the size of >your wallet/checking account? My other question is. Will any of us >remember to tell the New Millennium babies that they are the ones who will >see the "REAL Y2K bug"? Hey, I've got a Y2K issue. My fax driver/app "Delrina WinFax Lite 3.0 Fax Administrator" can't recognize years 00 to 09 as the send date. I have to go and change the send date to 99 or before. Neat. -Drew
Having assured everyone that Sidekick98 was Y2K OK, Starfish software's calendar/scheduler product developed a bug last week in which attempts to view your daily appointments produced a complaint of "Invalid file to complete this action! mast:wk". Some users also reported troubles with past "to-do" items not done failing to appear on the current day's list. Starfish have released <A HREF = "ftp://ftp.starfish.com/pub/sk98/sk98patch.exe">a patch</A> that certainly fixes the first problem and may fix the second too (I didn't have it so I cannot report on this). Although there is a Sidekick99, many users refuse to "upgrade" because the feature set in '99 is a feeble subset of the more powerful '98. No word from the company on what was missing from their testing procedure. A. Michael Froomkin, U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 http://www.law.tm froomkin@law.tm
The approximately 100,000 merchants using CyberCash's IC Verify transaction software were given the opportunity to install a free upgrade for Y2K, but some of the merchants apparently did not get the fixes. Those who did not do so are apparently rebilling each customer transaction in the new year once each day until the fix is installed. Visa and Mastercard have installed software that attempts to catch the multiple transactions, but you'd better check your statements anyway.
In one of many reports of off-by-one-hundred Y2K effects, a few dozen Florida truckers received bills saying the were 100 years late in payments. Some people received bills for 100 years' back interest. There were even reports of people whose bank accounts temporarily showed 100 years' accumulated interest. No surprises there to long-time RISKS readers. Asymmetrically, we have also had a few reports of people being credited with 100 years worth of interest, although these seem rather specious if you are getting interest from 1900 to 1999, rather than from 1999 to 1900.
I spent the new year in Manhattan and yes, I was in Times Square new year's eve. After the ball dropped, I started calling friends to wish them a happy new year, and I was not able to make a single call on my Sprint PCS phone despite the very strong PCS signal I got. What made it worse was I could not receive any calls or voice mail during the day on the 1st and my outgoing calls (including calls to check voice mail) were switched to digital roaming calls despite the fact that Manhattan was in Sprint's service area. The problem lasted all day on the 1st, and into parts of the morning on the 2nd. A later conversation with a Sprint's service representative revealed that Sprint's network was jammed in several metropolitan areas including New York city during the 1st, and they were routing some of their traffic through Bell Atlantic or AT&T's network, which explained the mysterious roaming calls. Chenxi
MKS Toolkit Scheduler (Version 6.1) seems to have a problem with the Y2K date rollover. The application runs fine and must work off the system clock which also appears to be fine . The "Next Event" status how ever, shows that the next backup is on June 9, 2005 even though it performs daily backups properly. Ray McCormack, Solutions Consultant, McCormack Consulting 13215-C8 SE Mill Plain blvd. PMB 242 Vancouver, WA 98684 1-360-241-3092
I'm sure you'll know about this, but just in case: http://y2kmistakes.com has a wonderful archive of screenshots of Y2K affected sites. http://catless.ncl.ac.uk/Lindsay
Some amusing, generally harmless, Y2K snafus can be seen at the following URL. Look under "affected sites" in the upper left-hand corner. http://kwikware.com/y2kmistakes/
Sorry, I can' help this: On http://www.year2000.com/y2kbugbytes.html We have the following headline on Jan. 6, 2000: Year 2000 Bug Bytes Updated January 5, 1900 at 23:21 (UTC) Pete de Jaeger has a nice article on "Why no Chaos?" at http://www.year2000.com/y2kchaos.html, however. Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin 13353 Berlin, Germany weberwu@tfh-berlin.de http://www.tfh-berlin.de/~weberwu/
Newsgroups: alt.fan.cecil-adams [Forwarded to RISKS by msb@vex.net (Mark Brader)] radio2@bigfoot.commm wrote: > I was just in my friendly neighborhood health food store. Got into a brief > discussion with the guy behind the counter, about Y2K. He pointed out a > box of Barbara's Cereal, which carried an expiration date of July 1900! > Guess it's been sitting on the shelf, there at Flanagan's, for a mighty > long time ... > -- Geno I win. Ages ago I realized that my driver's license says it expired in 1000. Boy, what's the penalty for driving on a millennium-overdue license? Dana W. Carpender http://www.holdthetoast.com Author, How I Gave Up My Low Fat Diet -- And Lost Forty Pounds! [In case you wondered, YES, it showed 1000 as a 4-digit year. She lives in Indiana. MSB]
The National Transportation Safety Board maintains a database of all aviation incidents in the US, and provides web access to capsule descriptions of various accidents. These are available by month (http://www.ntsb.gov/aviation/months.htm), so I suspected that there might be some issues with the display or breakdown of the data once we rolled into 2000. The website seems to be working correctly, however, with the exception of a strange entry in January 2000. The accident location (normally City,State) shows "TESTVILLE" and the link is http://www.ntsb.gov/aviation/DCA/99A999.htm (note the 99A999.htm is normally an incident number). The link itself fails to be retrieved, so I assume the test data has been removed from part of the database. I'm sure we'll see many similar manifestations of Y2K testing in the coming weeks and months. John Clarke P.S. Apologies to the citizens of TESTVILLE if it really does exist and a plane crashed there this month.
I guess I'd only say that if a web developer wanted to use dates in JavaScript, they would: 1) have to do a lot of nit-picky detective work, reading documentation from Netscape, Microsoft, and the EMCA, to discover the "correct" way to display the year, 2) end up with a script that still wouldn't work on most people's browsers, and, 3) learn that they shouldn't have bothered anyway, since some standards group will no doubt later change the "standard" yet again in a way that breaks all previously written scripts. Yeesh. All this pain, sweat, and confusion just to display a bloody date on a bloody web browser. Small wonder that software reliability issues are gaining attention in the new century... Andrew D. Fernandes <mailto:andrew@cryptonym.com>, Cryptonym Corporation <http://www.cryptonym.com> Telephone +1 919 469 4714
Call me naive, but I can't help marvel, risks or not, at what is going on. Here I am, on the penultimate day of the millennium (OK, I know, that will be next year, but what's wrong with celebrating twice?), listening through minuscule speakers on my computer to a broadcast of perfect sound quality from a site half-way around the world. It's playing something I know, but I can't just recall what it is. So I catch four Italian words on the fly and type "senza perdere un momento", not forgetting the quotes, into AltaVista. A second later, and perhaps fifteen seconds after I first asked myself the question "what is this?", I have the answer, thanks to someone at Stanford who keeps the full text of Donizetti's "Don Pasquale" on his Web pages. Just a few years ago none of this would have been possible. I wouldn't have had a clue where to begin my search. Even a trip to the UCSB library would have been unlikely to help. The prospects of using computers for advancement of human knowledge are all around us; they are staggering. Let's remember this as we continue (as well we should) worrying about the associated risks. Bertrand Meyer, Interactive Software Engineering/Monash University http://eiffel.com, http://tools-conferences.com
Now that the media is ranting about the $600 billion "down the drain" (CBC radio this morning), it makes me wonder what would the cost have been to build everything Y2K-compliant from the start (assuming perfect foresight)? And what would that cost be in year 2000 dollars? Don Cleghorn don@globility.com [For those who think money was wasted, it is intriguing to see how messy the situation was as recently as six months ago. There has been some real progress, which probably never would have taken place in the absence of the Y2K hype. But the old technique for keeping elephants away probably would not have worked. (See, there are no elephants!) But, it was nice to see that there was not much panic, as Paul Saffo pointed out in a KCRW radio show we were on in L.A. a few minutes ago.) PGN]
At 9pm on 1 Jan 2000, I turned the radio to a local station in Dunedin, NZ to hear the news reader announce the time to be 11 o'clock. As I continued to listen I realised that the news being read was from the previous evening. At 10pm the same news was re-read. It would appear that a computer, either at the radio station or at their news supplier, was trying to play the most recent tape based on a 2-digit year. The risks are obvious, confusion about both the time and the news, and a lack of information about what really is happening in the world. The real irony was that the lead story was about an expected lack of Y2K problems. Then again maybe its a cunning strategy to avoid Y2K by never quite getting there. [Too bad it was not in Australia or Austria. Then it might have been an Austrich sticking its head in the sand to pretend that Y2K had not yet arrived. PGN]
Shortly before midnight on 31 Dec 1999, at about 11:15 PM, I switched my Nokia 6188 cell phone on. Having enabled the Field Test menu on the phone (enter the code: *3001#12345#), I went to Field Test screen 07 to view the current date and time. Instead of displaying "Dec 31, 1999", the screen was flashing and read out "On 71, 1999" with the correct time printed below. At midnight the year correctly switched to 2000, but the display continued to flash "On 71, 2000". This behaviour continued until Saturday night, (Jan 1 2000), when I switched the phone off and back on a few minutes later. For a brief moment the Display read "Jan 01, 1980", then "Oct 27, 1990", and finally "On 71, 2000". After leaving a movie at 12:45 AM Sunday morning, I switched my phone back, and the display did not flash, instead it said "Jan 01, 2000", that seems fine, except that it was 2nd, not the 1st. My phone still seems to think that it is the 1st on this Sunday night. It should be noted that a friend of mine who purchased the same phone around the same time I did (June 1999) was seeing the same behaviour. Whereas a friend who purchased the same model phone in early December did not see any of the above strange behaviour. Finally, pressing MENU - 8 to view the Calendar works fine. Leaving me at the current date. Version information: (Field Test screen 61) Nokia 6188, 430SD3a2.nef, 05/18/1999, NSD-3AX If anyone could shed any light on this strange glitch, please post a reply. [to Jari, please. Kiitos. PGN] - Jari Takkala
It seems that little has been discussed about Y2K outages resulting from telephone systems being overloaded as midnight passed around the world. Here in Toronto, Bell Canada warned about not picking up our telephones shortly after midnight to check for a dial tone, as everyone doing so may overload the system. Well, looks as if many did not head the warning (myself included). The cellular networks here were extremely overloaded, resulting in fast-busy signals or silence up until about forty-five minutes past midnight. Calls to 611 (phone service and client care) to check my cellular bill would go through, but instead of the usual voice prompts, I was greeted with a message along the lines of "Due to the unusually high volume of calls we are currently experiencing, there is a long waiting period for a service rep...". I did not get a chance to make any calls on the landline, but a friend calling 411 (Directory Assistance) had to wait for about 5 minutes before her call was answered. Another friend said he was also greeted with several fast-busy signals or silence when attempting to make calls. Jari Takkala
We will find the most prevalent problem with the new year as being what I call the "Year 97,98,99,100" problem. These are not necessarily benign problems of display only. I became first aware of this flaw a year ago while testing software that I had out in the field and traced the problem back to the compiler date kernels. I found that the Borland kernel (which is licensed from MS, the foundation classes) and the MS kernel was flawed. When I discovered this problem I was stunned to see such poor programming come from MS or anywhere else. I was only able to test Borland and MS compilers because they where the ones we used in house here, though I suspect the problem might be more wide spread. I did research and I did find MS acknowledging the problem in the first few days when they posted Y2K fixes in late 1998. Their web-site actually classified this problem as severe and could cause data corruption. What was interesting is that this problem disappeared from its predominate placement on the Y2k page within 3 days after its posting. I was alarmed when I realized that ALL software compiled prior to a certain date will have this year 100 problem. This means that most of all PC legacy software applications will be suddenly broken or untrustworthy and now you are indicating that non-PC systems are affected also. The RISK categories for this problem fell into three groups of programmers: The first group never tested to see if their program ran correctly or considered certain software no longer being used so no corrective action was taken. The second group of which I was initially a part of, said to themselves, "I don't do any date comparison in my application so I can't have a Y2K problem. I just capture the date for display or store it with each record. No date manipulations at all." Well I was wrong but was fortunate to test for it early last year and issue a correction. This problem will crash most systems or cause erratic problems from memory corruption. I captured the date and time with each record that was created and stored it out. Which is pretty common DP practice. For as long as I have been programming, over 28 years now, the year was always returned as a 2-digit number. Imagine my surprise when it became a three-digit year (100). This meant that the variable used to store the date which was sized at 8 characters now was being fed 9 characters, which meant that everywhere I had a date as mm/dd/yy it was now being fed mm/dd/yyy. The third digit in the year stomps on top of whatever the following memory space variable is. Which I'll leave up to the reader to imagine all the potential problems that might happen. If you create arrays using these dates the problem just gets worse. Now your program may continue to run, but due to the nature of memory corruption it may just act erratic or hang or just continue trashing your database as you save out new or modified records. Even if you used a compiler that had bounds checking or you yourself did such, the year would still become the year 10. Why you would have been inclined to do bounds checking of this nature is beyond me. It would be like performing a check to see if there were more than 60 seconds in a minute. Does the sun rise from the east? Yes, everywhere but two points on the globe. The third group found this problem but saw the 'fix' as just simple math, so simple that they didn't test the results of their math. This group falls into the fix makes it worse group. The fact that there is increasing numbers of reports of the year 100 problem inclines me to believe there were a large group of programmers who just said "I don't do any date comparisons" and got caught and a lot of people doing rushed last minute faulty fixes when discovering a year 100. Planes didn't fall out of the sky, but we just lost the reliable use of decades of older programs that has a date displayed somewhere because some idiot thought that the year after 99 was 100. Robert Rathbone, President, Alchemedia Communications And Design, Inc. P.S. I do have an large application written in 1991 that we thought no one would be using for more than a couple of years not concerned about any dates then. There are a dozen or so companys still running the DOS program today. We only sold maybe 20 systems of this application. The companies didn't want to pay for the programming to bring it up to date and I didn't really want to modify such a large application (150k+ lines of code). I just told them to set the date back to a year that matches the year 2000 and the same for 2001. They were happy that they could still run a very reliable program and we were happy not to go through the grief of debugging and introducing destabilizing bugs.
My Y2K story: at midnight, the X-10 controller that I use to control my home's lights apparently froze. (I use X-10 to automatically turn lights on and off over the Jewish Sabbath, when direct intervention in an electric circuit is forbidden.) Fortunately, the kitchen and dining room were left in an "on" state, so we weren't left in the dark on Saturday afternoon, and resetting the timer seems to have unfrozen it. [...] Not truly Y2K-related, but worth noting in Risks, was that *The New York Times* corrected a 102-year-old error in their issue numbering as of 1 Jan 2000. It appears that on 6 Feb 1898, a careless copyboy figured that the issue after 14,499 would be 15,000; since each day's issue number was "computed" by looking at the previous day's issue and adding 1, no one caught the error for over 100 years. The current "newsroom assistant" (no longer a copyboy) in charge of typing in the number each night starting wondering about whether an error had ever been made, worked out what the current number should be (using a spreadsheet program), and tracked down the gap. *The Times* reverted its issue number by 500 and "regrets the error."
The Year 2000 Information Center - Year 2000 Bug Bytes http://www.year2000.com/y2kbugbytes.html has the following line: Updated January 3, 1900 at 14:50 (UTC) same for their page of press clippings http://www.year2000.com/y2karticles.html Updated January 3, 1900 at 14:44 (UTC) also this: Technology News U.S. Nuclear Plants See Minor Y2K Glitches (01/02/00, 9:44 a.m. ET) TechWeb Seven U.S. commercial nuclear reactors experienced minor Y2K computer-related problems, but none affected safety systems and were quickly fixed, government officials said Saturday. The plants saw malfunctions with computer systems used to support physical plant access control, the monitoring of operating data, and the calculation of meteorological data. <http://www.techweb.com>
While attempting to copy a large .mpg file to CD-ROM today (1/3/2000), my application (Easy CD Creator) gave the following error message: "The item "***(name omitted)***" cannot be added because the date and time is corrupt. Do you want to continue adding other items?" Upon checking the file properties, it showed a creation date of 1/3/2000 and a last accessed date of 1/3/2000, but a modified date of 9/1/2099!!!!!! Just offhand I would say this is a Win95 problem -- when it saw that the file was modified before it was created, the brilliant geniuses at Microsoft decided to simply say, "Oh, it must be that pesky Y2K bug -- add a hundred years -- THAT'LL fix it!" However, for some reason, Easy CD Creator doesn't seem to be able to recognize this date as being valid. The workaround I found was to open the huge file in an MPG editing program, and then re-save it under a new name. This normalizes all dates to the year 2000. There may be easier ways of handling this, but I haven't tried any others.
Uh-oh. This JavaScript snippet actually is CORRECT. As defined in the JavaScript standard, the "year" field should indicate the number of elapsed years since 1900. What was going on? It turns out that Fujitsu's web page displays correctly under Netscape-4.7, but not on MSIE-5.01. I'm not sure about MSIE4.x. The risks? It seems that Microsoft has yet-again thrown a patch into its operating system without checking for standards compliance, or doing a lot of regression testing. JavaScript's "Date" function has always been Y2K compliant; programmers often just haven't used it properly. Andrew D. Fernandes <andrew@cryptonym.com>, Principal, Cryptonym Corporation <http://www.cryptonym.com> +1 919 469 4714
Yet another variation: I used an FTP client to download a file, which ended up bearing the date "Dec 10, 1909", even though the file's creation date as listed on the server was "Jan 2, 2000". Checking in debug mode revealed the culprit: a MDTM request returned "191000102072639" which is composed of the now familiar "year 19100"; the FTP client breaks this down to year 1910, month 00 -- which ends up as the last month of 1909. Amos Shapir, nSOF Parallel Software, Ltd., Givat-Hashlosha 48800, Israel Tel: +972 3 9388551 Fax: +972 3 9388552
Hi. I use a program to chime the hour and announce the date and time. It is "Talking Clock" version 3.10. and is Copyright 1993 by Aristosoft, Inc. Earlier it announced "Friday, December thirty-first, nineteen ninety-nine". The next day it announced "Saturday, January first, twenty". Bruce Stein on the Line <bruce42@pacbell.net>
Back in 1984, I wrote a program that ran under System 5 Unix and was tasked with taking care of all things information at a law office. A few years ago, the people who use the system decided to change over to some new commercial software, and I indicated that I would therefore not have to and would not do any Y2K conversion. Come several years later, the 'conversion' to the new system is still running behind the times, and as Y2K looms, I warn the folks who use the system that it is NOT Y2K compliant and that, while most everything should work right through the year 10K and beyond, there was one particular place where I had placed the digits 19 in the code to deal with the fact that the date function (at that time) didn't have a 4-digit mode. Ater a third warning and assurances that this system was NOT Y2K compliant, they assured me that they would be converted in time. Come this morning, lo and behold, they are not quite fully converted yet, and are still running my system of 15+ years ago, but surprise of surprises, my system is still doing the right thing as far as they can tell, but the replacement system has destroyed itself. Now I told them again this morning that my system is not Y2K compliant and that they should watch for anything that comes out 19 instead of 20 and manually change it until the new system works, but for the life of me, I cannot figure out how it is still working, given that 19 is hardcoded into it. Ah well, I guess this Y2K thing was just overblown. Even things that aren't supposed to work seem to be working. Fred Cohen at Sandia National Laboratories 1-925-294-2087 Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:1-925-454-0171 Fred Cohen - Practitioner in Residence - The University of New Haven
> Time left to January 1 2000: > -1 years, 11 months, 29 days, 14 hours, 21 minutes, 45 seconds They've obviously applied the Y2K fix since your post. It now reads: -1901 years, 11 months, 29 days, 2 hours, 6 minutes, 5 seconds Daniel NortonMatthew Byng-Maddick <mbm@colondot.net> Sun, 2 Jan 2000 23:44:06 +0000 (GMT)
Interesting to me that most of the bugs seem to be occurring in the systems that were supposed to countdown to 12 midnight 1/i/'00. A lot of these systems are, of course buggy in design, in that they will have no use after a certain date, and are therefore buggy from conception through to implementation. Also the other interesting thing about most of the reported bugs, the localtime() feature, is that the Camel Book (2nd Edition) is very clear about how you should use the year component, ie. not just "19".(localtime())[5]. Just my 2p worth on this. Matthew Byng-Maddick mbm@colondot.net http://colondot.net/
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]William Ehrich <ehrich@minn.net> 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.
Unser Internetangebot zum Jahr-2000-Problem ist in
ständiger Erweiterung begriffen, da wir Ihnen stets aktuelle Informationen
bieten möchten. Diese Information soll besonders kleinen und mittleren
Unternehmen sowie auch Privatpersonen helfen, Ihre Computer und
Lokalen Netzwerke vor dem "Gau" beim Übergang ins Jahr
2000 zu schützen. Wir empfehlen Ihnen, hier öfters mal vorbeizuschauen.
Wenn Sie diese Seiten irgendwo "einlinken" wollen, so bitte die extra hierfür
aufbereitete Seite
"http://agn-www.exvtc.de/jahr2000/index.htm"
Die Informationen haben wir sorgfältig nach bestem Wissen und Gewissen
zusammengestellt. Eine Gewähr für die Richtigkeit der Aussagen, der Funktionalität
und Qualität der vorgestellten Programme können wir aber nicht übernehmen.
Insbesondere weisen wir darauf hin, daß Informationen auf den zugelinkten Webseiten
Aussagen und Ansichten der jeweiligen Autoren (und Firmen) zum Jahr-2000-Problem darstellen.
kennzeichnet deutschsprachige
und kennzeichnet englischsprachige
Informationen.