precedence: bulk
Subject: Risks Digest 20.73
RISKS-LIST: Risks-Forum Digest Monday 3 January 2000 Volume 20 : Issue 73
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:
http://catless.ncl.ac.uk/Risks/20.73.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Palm Springs airport radarless for almost two weeks (PGN)
Y2K fix cost? (Don Cleghorn)
New Year's Eve 11pm news repeated hourly in NZ: 99 > 00 (Callum McKenzie)
Nokia phone not Y2K compliant? (Jari Takkala)
Effects of Y2K on mobile and telephone networks (Jari Takkala)
Year 97,98,99,100 (Robert Rathbone)
Y2K Filemaker Pro (Mary Shafer)
Word Perfect 5.1 and medical transcription ALL over (Don Taylor)
X-10 controller not Y2K-ok (Andrew M Greene)
Timely updates and Y2K nuclear-plant glitches (Doneel Edelson)
Disregard those OS Upgrade error messages; they're OK! (Michael Cook)
Interesting Win95 Y2K bug? (Roger Galliett)
Risks in poor library design (Ben Elliston)
Unix98 localtime (John J. Francini)
Re: Giga-byte Javascript Y2K (Kai Birger Nielsen, Andrew Fleisher)
Javascript considered harmful (Martin Minow)
Microsoft MSIE Y2K Insanity (Andrew D. Fernandes)
California DMV Y2K snafu (Cliff Sojourner)
Y2K FTP problem (Amos Shapir)
Y2K funny computer error in Talking Clock (Bruce Stein)
Y2K compliant? Not possible! (Fred Cohen)
Re: Time left until Y2K (Daniel Norton, Matthew Byng-Maddick)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 2 Jan 100 17:00:08 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Palm Springs airport radarless for almost two weeks
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.]
------------------------------
Date: Mon, 3 Jan 2000 09:16:56 -0500
From: "Don" <
[email protected]>
Subject: Y2K fix cost?
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
[email protected]
[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]
------------------------------
Date: Mon, 3 Jan 2000 14:01:13 +1300
From: Callum McKenzie <
[email protected]>
Subject: New Year's Eve 11pm news repeated hourly in NZ: 99 > 00
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]
------------------------------
Date: Sun, 2 Jan 2000 23:02:59 -0500 (EST)
From: Takkala <
[email protected]>
Subject: Nokia phone not Y2K compliant?
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
------------------------------
Date: Sun, 2 Jan 2000 23:28:09 -0500 (EST)
From: Takkala <
[email protected]>
Subject: Effects of Y2K on mobile and telephone networks
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
------------------------------
Date: Mon, 03 Jan 2000 03:29:28 -0500
From: Robert Rathbone <
[email protected]>
Subject: Year 97,98,99,100
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.
------------------------------
Date: 03 Jan 2000 11:53:19 -0800
From: Mary Shafer <
[email protected]>
Subject: Y2K Filemaker Pro
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
[email protected]
------------------------------
Date: Sun, 2 Jan 2000 22:54:54 GMT
From: Don Taylor <
[email protected]>
Subject: Word Perfect 5.1 and medical transcription ALL over
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
------------------------------
Date: Mon, 3 Jan 2000 15:32:49 -0500 (EST)
From: Andrew M Greene <
[email protected]>
Subject: X-10 controller not Y2K-ok
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."
------------------------------
Date: Mon, 3 Jan 2000 12:08:06 -0500
From: "Edelson, Doneel" <
[email protected]>
Subject: Timely updates and Y2K nuclear-plant glitches
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>
------------------------------
Date: Mon, 20 Dec 1999 09:09:42 -0600
From: Michael Cook <
[email protected]>
Subject: Disregard those OS Upgrade error messages; they're OK!
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
------------------------------
Date: Mon, 3 Jan 2000 09:57:14 -0900
From: "Roger Galliett" <
[email protected]>
Subject: Interesting Win95 Y2K bug?
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.
------------------------------
Date: Tue, 4 Jan 2000 06:44:47 +1100 (EST)
From: Ben Elliston <
[email protected]>
Subject: Risks in poor library design (Re: RISKS-20.72)
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.
------------------------------
Date: Mon, 3 Jan 2000 10:56:42 -0500
From: "John J. Francini" <
[email protected]>
Subject: Unix98 localtime
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,
[email protected]
------------------------------
Date: Mon, 3 Jan 2000 10:34:21 +0100 (MET)
From: Kai Birger Nielsen <
[email protected]>
Subject: Re: Giga-byte Javascript Y2K
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 (
[email protected])
[also noted by Finn Poschmann <
[email protected]>. PGN]
------------------------------
Date: Mon, 3 Jan 2000 21:10:11 +1100
From: Andrew Fleisher <
[email protected]>
Subject: Re: Giga-byte Javascript Y2K
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 <
[email protected]>
------------------------------
Date: Mon, 03 Jan 2000 09:46:28 -0800
From: Martin Minow <
[email protected]>
Subject: Javascript considered harmful
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,
[email protected]
------------------------------
Date: Mon, 03 Jan 2000 11:14:54 -0500
From: "Andrew D. Fernandes" <
[email protected]>
Subject: Microsoft MSIE Y2K Insanity
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 <
[email protected]>, Principal, Cryptonym Corporation
<
http://www.cryptonym.com> +1 919 469 4714
------------------------------
Date: Sun, 02 Jan 2000 21:57:37 -0800
From: Cliff Sojourner <
[email protected]>
Subject: California DMV Y2K snafu
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.
[email protected]
(408) 527-7637 170 W. Tasman Drive, SJ CA 95134 bldg H2/cube E2-7
------------------------------
Date: 3 Jan 2000 16:21:40 GMT
From:
[email protected]
Subject: Y2K FTP problem
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
------------------------------
Date: Sun, 02 Jan 2000 23:35:06 -0800
From: Bruce Stein <
[email protected]>
Subject: Y2K funny computer error in Talking Clock
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 <
[email protected]>
------------------------------
Date: Mon, 3 Jan 2000 12:45:23 -0800 (PST)
From: Fred Cohen <
[email protected]>
Subject: Y2K compliant? Not possible!
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 -
[email protected] - tel/fax:1-925-454-0171
Fred Cohen - Practitioner in Residence - The University of New Haven
------------------------------
Date: Sun, 02 Jan 2000 21:55:05 -0500
From: Daniel Norton <
[email protected]>
Subject: Re: time left until Y2K (RISKS-20.72)
> 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
------------------------------
Date: Sun, 2 Jan 2000 23:44:06 +0000 (GMT)
From: Matthew Byng-Maddick <
[email protected]>
Subject: Re: time left until Y2K (RISKS-20.72)
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
[email protected] http://colondot.net/
------------------------------
Date: 13 Dec 1999 (LAST-MODIFIED)
From:
[email protected]
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <
[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
.MIL users should contact <
[email protected]> (Dennis Rears).
.UK users should contact <
[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to
[email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available:
ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 19" for volume 19]
or
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
Also, new AUSTRALIAN archive
http://mirror.aarnet.edu.au/risks/
PostScript copy of PGN's comprehensive historical summary of one liners:
illustrative.PS at ftp.sri.com/risks .
------------------------------
End of RISKS-FORUM Digest 20.73
************************
