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…
The Palm Springs radar system was seriously undependable in December, and was finally shut down for almost two weeks by the FAA. Controllers could not track planes below 8000 feet via radar, and resorted to radio and visual contact. The FAA of course said their were no safety problems (presumably because of much wider spacing of planes — one plane at a time in 30-mile regions). Nevertheless, at least 15 incidents of avoidance based on cockpit warnings were reported in 11 days. Two cases involved distances of about 400 feet, both involving smaller aircraft near commercial planes. [Source: *Los Angeles Times*, 31 Dec 1999; PGN-ed] [I have a bunch of other non-Y2K stuff pending. Please be patient.]
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.
I had a Y2K failure of sorts--the 24 December Y2K upgrade to Filemaker Pro on my laptop turned it into a keyed (networked) application, rendering it useless to me because there was no key access routine installed, naturally, since the computer is supposed to work unnetworked. As a result, I couldn't do my time sheet, or even print out a blank form, until I was able to find another PC that I could get on without a password. Apparently, the set-up routine said that it would make the application keyed, but the secretary required to hustle around and update everyone's computer didn't understand what it meant and continued the application. She didn't know that laptops have to run unkeyed, but couldn't let me, who knew that, do the installation. Mary Shafer, Lead Handling Qualities Engineer, SR-71/LASRE, NASA Dryden Flight Research Center, Edwards, CA shafer@rigel.dfrc.nasa.gov
A significant portion of the medical transcription community still happily makes use of Word Perfect 5.1 for MSDOS, silently turning your doctor's report into bits. In sci.med.transcription someone posted a short note explaining how to confirm that the date format was set correctly to handle four-digit years. And many readers used this information to check and perhaps correct the settings. However, after confirming that settings here were already correct, and that the software would correctly insert appropriate dates into documents, I saw that when displaying the list of files in directories it would show the date as "01-01-:0" Other users discovered that for other years the date might be ";0" or "<0" or other interesting things. Someone then posted the following note: > According to the Corel WP5.1 web site regarding Y2K issues, this is > just the way the dates are displayed in File Manager. Check out this > URL for details: > http://www.corel.com/year2000/wp_5_1_dos_advanced_users.htm
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>
As part of becoming Y2K compliant, Windows NT machines here are being
upgraded from NT 4.0 service pack 4 to service pack 5. A canned script has
been made available to those who need to upgrade their PC.
Upon starting this script, I got the following message in a pop-up window:
"Wait one moment while we add you to the Local Administrators group.
You may see several errors as the process runs,
this is normal, do not be concerned."
Reassuring?
Another pop-up window later in the upgrade process says:
"Part of the Update can generate errors.
Please do not be alarmed.
If you get any messages that say you do not have
rights to update, call the helpdesk..."
So, how can we differentiate between legitimate errors and those that
we are to disregard? Or errors that mask other errors, and so on.
What the pop-up windows did *not* say, but maybe implied, is:
"Pay no attention to that man behind the curtain."
-- Michael Cook
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.
Recent postings about "Y2K" glitches detected on web sites highlights an
important risk in software engineering--and more precisely, the design of
libraries and APIs.
The C library function, localtime(), breaks a binary date representation
into its component parts--these parts are collectively stored in a struct
tm. One field of this structure that is of concern is tm_year, which,
according to my Unix system's man page, is:
tm_year The number of years since 1900.
This is indeed clearly documented. But most programmers only read
documentation when they can't get things to work, or they don't work as
they expect them to.
Last century :-), programmers examined the value of this field, and
thought, ``Oh, it's 98--this must be the year without the century
portion'', and proceeded to tack "19" in front. At the same time, they
would have tied a piece of string around their finger to remind them to
change this to "20" at the end of 1999. (!)
I think it's probably safe to say that this aspect of the library is poorly
designed. The empirical evidence is before us--many, many programmers
misunderstood and subsequently misused this structure, causing widespread
programming errors. If the library had been designed differently, so that
the complete value of the year was kept in the structure, this would not
have happened. My research suggests that the tm_year field has always been
of `int' type, so the reason for using the number of years since 1900 was
probably not to economise storage.
The problem is that it's not so simple as that. The UNIX98 standard changed the localtime() function so that the year value is redefined to be the "year in the current century" rather than "years since 1900". On a system that has been patched to comply with UNIX98 _after_ your suggested change was made, the code would break. It's better to use a function that gets the current century and then adds (year % 100) to it, or gets the current 4-digit year direct from the OS. This covers more bases. John Francini, francini@progress.com
They seem to have "fixed" it now by changing the year += 2000 to year += 0; Welcome to Jan 3 100. http://www.giga-byte.com/gigabyte-web/newtop.htm Also note that older browser may well run Javascript 1.2 and so actually display Jan 3 2000. I wonder if they tested this on an old browser ? Birger Nielsen (bnielsen@daimi.au.dk) [also noted by Finn Poschmann <fposch@cdhowe.org>. PGN]
More interestingly is that a pc I have with a giga-byte motherboard supplies the year 2094 on boot, even after correcting the year to 2000 and applying the patch supplied by giga-byte. Andrew Fleisher <andrew8@start.com.au>
The Javascript Y2K bug I wrote you about yesterday is, unfortunately, uglier
than I had realized: apparently, Netscape's JavaScript returns (year - 1900),
while (today), Internet Explorer returns the actual year. I fixed (at least
for now), my bug by writing:
revdate = new Date(document.lastModified);
year = revdate.getYear();
if (year < 1900) {
year = year + 1900;
}
This works on the four browsers I tried today, but I don't guarantee it will
work on a fifth. (Standards are wonderful: everyone should have a few).
Martin Minow, minow@pobox.com
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
The registration and stickers for a boat I own arrived in the mail 1999/12/31. the "date fee received" column says "22/30/2999". oh well, at least the registration is good until 2000/12/31. Cliff Sojourner, Cisco Systems Inc. cls@cisco.com (408) 527-7637 170 W. Tasman Drive, SJ CA 95134 bldg H2/cube E2-7
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 Norton
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/
Please report problems with the web pages to the maintainer