precedence: bulk
Subject: Risks Digest 21.20

RISKS-LIST: Risks-Forum Digest  Saturday 13 January 2001  Volume 21 : Issue 20

  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/21.20.html>
and by anonymous ftp at ftp.sri.com, cd risks .

 Contents:
Dell, Unisys and Microsoft -- DUMvoting 1.0! (Gene N Haldeman)
San Francisco Airport radar phantom flights (PGN)
Cell phone in luggage alarms avionics (David Kennedy)
Testimony before the U.S. Civil Rights Commission (Douglas W. Jones)
No human finger will actually pull a trigger... (Daniel P. B. Smith)
Swiss debit-card system broke down (Andre Oppermann)
Subject: Re: The Chinook Crash (Peter B. Ladkin, Mike Beims)
Armchair Chinook RISKS analysis is misplaced (Nathan K. Pemberton)
Since when is Northern Ireland considered a war zone? (Chris Warwick)
Oregon Jurors summoned for 1901 (Aydin Edguer)
Y2K bug in Millennium clock (Mike Palmer)
Re: 54 weeks in a year? ('o-Dzin Tridral, Paul van Keep)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Fri, 12 Jan 2001 17:56:28 -0500 (EST)
From: Gene N Haldeman <[email protected]>
Subject: Dell, Unisys and Microsoft -- DUMvoting 1.0!

 [It is never too early for April to roll around.  PGN]

"This Message Can Not Be Considered Spam, Even Though It Is.
Some Law That Never Was Enacted Says So."

Dell, Unisys and Microsoft have joined together to produce:
 DUMvoting 1.0!

DUMvoting 1.0 is a simple 375k zipped download which you can install on
your machine tonight, and vote for President tomorrow!  Worried about
hanging chad?  Not with DUMvoting 1.0!  No, your vote will travel over
HEALTHY SAFE Internet connections to our new DUMvoteCenter, located in my
next-door neighbor's basement where a 16-year-old computer genius known as
SWORDGANDALF will convert it into paper ballots in between Dungeons and
Dragons games.

(Note: During installation, a pop-up box may notify you that Back Orifice
is being installed.  This is normal.  For best results, please disable all
anti-virus software before installing DUMvoting 1.0)

NEVER AGAIN will you walk to a voting booth in the rain.  NEVER AGAIN will
you have to associate with the kind of people (and you know what I'm talking
about, I don't have to spell it out for you, do I?) who hang around the
voting area.  NO MORE messy contact with neighbors.  We have got it ALL
WORKED OUT for you.

And with our new SPEEDYEXITPOLL (c), you won't have to wait till midnight
for the outcome!  We will be sending our projections the day before the
elections, and our exit polls by 11:30 am on election day, saving you both
time and anxiety.

You must act fast, but DUMvoting 1.0 can be rushed to you for the low, low
price of $299.00 from our website at DUMvoting.com.  In addition, we will
send you OILMAN 3.2, the exciting new game from Microsoft:  Alaska's Up For
Grabs, And You Have Just Been Appointed To The EPA!  Plunder as you will,
but watch out for the charging caribou; we're told they have a "thing" for
the pipeline!

Order without delay.  Please include your Social Security number and any
recent medical bills.

*Sent by the Dell/Unisys/Microsoft Consortium:  "DUMideas Last Forever."

 [Note that DUM spelled backwards is MUD.  Must be symbolic.  PGN]

------------------------------

Date: Tue, 9 Jan 2001 14:48:49 PST
From: "Peter G. Neumann" <[email protected]>
Subject: San Francisco Airport radar phantom flights

The effort to install a new ground radar system for collision avoidance has
been set back by the appearance of phantom planes.  In earlier tests, a
Fremont-based component created ghost images for six nonexistent planes,
giving the appearance that two planes were heading for the same runway.  The
bug has finally been identified (according to a radio report), but it must
now be fixed, whereupon tests will continue.  [Source: Wire services, 8-9
Jan 2000]

------------------------------

Date: Fri, 12 Jan 2001 02:18:54 -0500
From: David Kennedy CISSP <[email protected]>
Subject: Cell phone in luggage alarms avionics

Reuters noted that a Slovenian Adria Airways airplane made an emergency
landing in Ljubljana on 9 Jan 2001 because of a cell phone in the baggage
hold had been left on.  It is asserted that the ringing phone corrupted
plane avionics and triggered a fire indicator.  [PGN-ed from
http://www.theregister.co.uk/content/5/15995.html]

I'm not certain how this should be classified:
 Remarkable detection of RFI without instrumentation?
 Remarkable instance of RFI?
 Remarkable instance of attributing flight instrument irregularities
   to RFI after an aborted flight?

Rhetorical:  If this had occurred in the US, would the incident have
counted against the airline's on-time statistics?

Dave Kennedy CISSP Director of Research Services TruSecure Corp.
http://www.trusecure.com

 [Also noted by Aydin Edguer at
   http://dailynews.yahoo.com/h/nm/20010110/od/aircraft_dc_1.html
 PGN

------------------------------

Date: 12 Jan 2001 22:46:04 GMT
From: [email protected] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Testimony before the U.S. Civil Rights Commission

My testimony before the United States Civil Rights Commission hearing on
allegations of election-day irregularities in Florida, Jan 11 2001, is
indexed on the Web at
  http://www.cs.uiowa.edu/~jones/voting/uscrc.html

My testimony was presented as part of the Expert Panel on Voting Technology,
along with testimony from Kimball Brace (Election Data Services) and John
Ahmann (Election Supplies Inc, the major Votomatic vendor).  My testimony
and Brace's testimony were in strong agreement on key issues involving
information that must be reported in the canvass of an election that is very
irregularly reported today.  I made strong statements about the risks of
standardizing election technology, as opposed to setting performance
standards, and I pointed out major problems with the current regulation of
computer software used in elections.

It was covered live on CSPAN, and if the USCRC follows its usual procedure,
multimedia transcripts of the oral testimony (audio and video) will be on
their web site in about a month.

Doug Jones <[email protected]>

------------------------------

Date: Fri, 12 Jan 2001 16:10:55 -0500
From: "Daniel P. B. Smith" <[email protected]>
Subject: No human finger will actually pull a trigger...

"Hemos," in an article in Slashdot, called my attention to
 http://www.cnn.com/2001/US/01/12/airborne.laser/index.html
This describes a weapons system under development, in which a Boeing 747
will carry an airborne laser capable of shooting down missiles.  According
to the article:

 No trigger man

 No human finger will actually pull a trigger. Onboard computers will
 decide when to fire the beam.

 Machinery will be programmed to fire because human beings may not be fast
 enough to determine whether a situation warrants the laser's use, said
 Col. Lynn Wills of U.S. Air Force Air Combat Command, who is to oversee
 the battle management suite.

 The nose-cone turret is still under construction

 "This all has to happen much too fast," Wills said. "We will give the
 computer its rules of engagement before the mission, and it will have
 orders to fire when the conditions call for it."

 The laser has about only an 18-second "kill window" in which to lock on
 and destroy a rising missile, said Wills.

 "We not only have to be fast, we have to be very careful about where we
 shoot," said Wills, who noted that the firing system will have a manual
 override. "The last thing we want to do is lase an F-22 (fighter jet)."

"I should've done better, didn't mean to be unkind.
Y'know that was the last thing on my mind..."

Daniel P. B. Smith <[email protected]>

------------------------------

Date: Wed, 10 Jan 2001 01:23:39 +0100
From: Andre Oppermann <[email protected]>
Subject: Swiss debit-card system broke down

On the day before Christmas Eve, usually the day with the highest turnover
of the year in all shops, the whole Swiss debit-card (EC-Card) processing
system of Telekurs broke down for more than two hours. Also getting Money
from ATM's and the processing of on-line MasterCard credit card payments,
which is handled by the same company, was interrupted.

In Switzerland the debit card "EC card" is quite popular and nearly everyone
with an bank account has one of these and also most people use it more or
less often. With the EC card, you can get money on ATM's and pay your goods
in shops and restaurant by swiping the card and entering your PIN code (no,
I don't go into that) like an credit card but the amount is deducted
directly and immediately from your bank account.

Now on Saturday 23 Dec 2000 at 13:15, a tape robot in an automated tape
library in the data center of Telekurs, the sole operator of all EC card
transactions, drops a tape on the floor which in turn leads to an error
propagation which shuts down the whole EC and MasterCard card processing for
approximately two and a half hours until 15:25.

The impact was quite unpleasant: thousands of frustrated people unable to
pay the Christmas presents for their loved, high revenue losses for the
shops on the most important day of the year and more than 100,000
transactions rejected.

What do we learn from this? The usual story: don't put all your eggs in the
same basket; have better failure recovery procedures in place for such an
important system, it should not be possible that a dropped tape brings the
processing of all transactions to a grinding halt.

For reference coverage by the media (in German):
http://archiv.nzz.ch/books/nzzmonat/0/$72NB6$T.html

Andre Oppermann

------------------------------

Date: Wed, 10 Jan 2001 13:09:16 +0100
From: "Peter B. Ladkin" <[email protected]>
Subject: Re: The Chinook Crash (Risks 21.18-19)

O'Connor (Risks 21.18) and Payne (Risks 21.19) have recently discussed the
1994 RAF Chinook transport helicopter crash on the Mull of Kintyre. And then
there is Ryan O'Connell's contribution, of which more later.

This is a very public discussion in the UK. It is said to be the first time
that the Royal Air Force has put an accident report in the public domain
(J.M. Ramsden, "RAF Safety after Chinook", Pilot, November 2000, p22) and
the controversy is sufficiently well developed for the UK defence minister
at the time of the accident, Sir Malcolm Rifkind, to have requested one of
his successors, Geoffrey Hoon, to set aside the finding of gross negligence
reached by Sir William Wratten (op.  cit., p23). It is probably the first
time ever that an Air Chief Marshall with authority to determine an accident
finding has written an article in the "popular" aviation press to explain
his finding (Air Chief Marshall Sir William Wratten, "Why those Chinook
pilots were `grossly negligent'", Pilot, August 2000, pp20-21).

Here is a brief description of the controversy. The Kintyre peninsula is
long, narrow, hilly (one hesitates to say "mountainous") piece of Scotland
whose end, the Mull of Kintyre, attains a height of 1404ft MSL (above mean
sea level) and is some 20km (13 miles) or so across the North Channel from
the nearest point of Northern Ireland. There is a lighthouse on the west
side of the Mull, directly below the "peak" (Ordnance Survey, Routemaster
Series, Number 3, Western and Central Scotland, ISBN 0-319-23003-1).

The flight was performed under a Visual Flight Rules (VFR) flight plan.
Visual flight was performed over the North Channel. Close to the lighthouse
on the Mull, the aircraft flew into Instrument Meteorological Conditions
(IMC) and hit ground at 810 feet, some 2,000ft below Instrument Flight Rules
(IFR) Safety Altitude for this sector of the planned route, calculated to be
some 2,800ft MSL, at a groundspeed calculated by the Air Accident
Investigation Branch to be some 150kts (Wratten, op. cit., p20. 1 knot (kt)
is 1 nautical mile (nm) per hour; 1 nautical mile is about 1.15 statute
miles).

The aircraft was equipped with a "SuperTans" GPS-based navigation computer
(Ramsden, op. cit., p21), and a VFR flight plan waypoint change was made, to
a waypoint some 87nm beyond the lighthouse, less than one nm from what was
to be the point of impact (Wratten, op. cit., p20).

The accident flight was equipped with neither a flight data recorder nor a
cockpit voice recorder. All parties to the controversy agree that we can
never know exactly what happened or why. We want to know why those highly
trained and experienced pilots flew into IMC on a VFR flight plan, and why
they did not perform regulation and trained maneuvers for such an
eventuality (slow down, climb immediately to at of above IFR Safety Altitude
for that sector, and immediately initiate a turn away or a 180-degree
reversal of course out of the IMC and back into the Visual Meteorological
Conditions (VMC) from whence you have just come. Wratten, op. cit., p20). We
shall never know the answers to these questions.

Flying into IMC while under VFR is one of the biggest killers of general
aviation pilots and their passengers. It also kills lots of professional
"bush" pilots in places such as Alaska. Every pilot, *every pilot*,
including students, is explicitly trained both to avoid doing that, and in
what to do if you do it anyway (namely, the maneuvers described above, which
are universal).

The Chinook helicopter, known as an HC.2 in UK military service, is a
twin-rotor heavy transport helicopter. It has one rotor fore, just behind
and over the cockpit, and one rotor full aft of the long fuselage. The HC.2
has a history of engine control system malfunctions (it is equipped with
Full Authority Digital Engine Control, FADEC), including uncommanded
"run-ups" (Ramsden, op. cit., p21). I take this to mean either an
uncommanded increase in power output or an uncommanded increase in rotor RPM
or both, but I don't know the exact history. Ramsden refers to Squadron
Leader Bob Burke, an RAF Chinook test pilot who has experienced "uncommanded
HC.2 rotor runaways" (op.  cit., p23). Furthermore, on the day of the
accident flight, one of the flight crew asked groundcrew to check the
navigation computer for "unusual GPS satellite tracking data. This check was
completed with `no fault found'" (Ramsden, op.cit., p21).

RAF Rule AP.3207.8.9 requires that there be no doubt in the case of a
finding of pilot negligence (Ramsden, op.cit., p21).

The controversy is briefly as follows. ACM Sir William Wratten asserts that
there is no doubt that the pilots flew into IMC conditions on a VFR flight
plan, and that there is no evidence of any technical malfunction which could
have caused them, against their training, to do so. His most reasonable
critics believe that there is indeed such doubt: for example, an uncommanded
run-up of the sort previously seen on the HC.2 could have caused the flight
pattern out of VMC into IMC and impact with the Mull (for example, Ramsden,
op. cit., p23, cites specific critics and an article in Pilot, October 1999,
which I have not read). Sir William replies that there is incontrovertible
evidence that the decisions and action of the pilots that led to flight into
IMC occurred independently of the occurrence of any such technical problem
or other factors presumed by some critics to be relevant (Wratten, op.cit.,
p21).

Much of the debate centers on the nature of RAF accident investigation
procedures, the nature of doubt and what kinds of considerations and
evidence lead to it (the nature of hypothesis, plausibility, and their place
in accident reports), the nature of justification and sufficient
justification under conditions of uncertainty, the purpose of accident
reports according to the RAF and whether the RAF's finding in this case
fulfills that purpose, whether there is a "culture of blame" in RAF incident
investigations, whether certain kinds of potential evidence was ignored, and
whether it should have been, and the effects of the finding on military
personnel as well as bereaved families, as well as the nature and role of
secrecy and openness in accident investigations.

I believe that civil societies need to consider such issues, and it is clear
that the RAF investigators and their commanding officers, as well as their
more reasonable critics, are acting in good faith and the controversy is
intellectually serious. I believe the debate is socially healthy. But then I
would, wouldn't I, given my interests in the analysis of complex system
failures? Well, not inevitably. I contrast the Chinook debate with that over
the 1988 Airbus A320 accident at Habsheim, on which debate I have expressed
my views, based on a first-level Why-Because Analysis, elsewhere (Section 5
of "Causal Reasoning About Aircraft Accidents, pp 344-355 of Computer
Safety, Reliability and Security, Proceedings of the 19th International
Conference, SAFECOMP 2000, ed. Koornneef and van der Meulen, Lecture Notes
in Computer Science, Volume 1943, Springer-Verlag, Berlin, Heidelberg, New
York, 2000).

Back to the RISKS contributions.  O'Connell (Risks 21.19) seems to believe
that the distinction between VFR and IFR doesn't exist for the UK military,
that the pilots "would have" been operating under some other unspecified
flight rules than VFR or IFR, that they were using terrain-following radar,
and that it is OK to perform terrain-following flight in IMC in the vicinity
of steeply-rising terrain, and that they might well have been doing that
because they were worried about anti-aircraft fire from terrorists.

Whereas O'Connor's and Payne's intellectual VFR has kept them and RISKS
readers well clear of clouds, O'Connell is flying, thankfully solo, into
IMC. Lighthouse keeper PGN, observing right on the border between VMC and
IMC, failed to notice despite his sense of smell that O'Connell was flying
directly into the Mull. It remains for our moderator only to explain the
pun.

Peter Ladkin

------------------------------

Date: Thu, 11 Jan 2001 16:18:49 -0500
From: Mike Beims <[email protected]>
Subject: Re: Chinook (Risks-21:18 and Risks-21:19)

The current debate about the June 2nd 1994, RAF Chinook Flight ZD 576 crash
into the Mull of Kintyre centers on the Full Authority Digital Engine
Controller (FADEC) used by that helicopter.  The FADEC was built by the
Textron company.

In Risks 21:18 John O'Connor makes a case for Controlled Flight
Into Terrain due to pilot error compounded by weather factors.

In Risks 21:19 Phil Payne makes a case that an additional risk was
not having a recording of the flight data.

Also in Risks 21:19 Ryan O'Connell makes a case that a risk mitigator for
low level flight in fog is the on-board terrain following radar and the
military pilots training for "Nap of Earth" flying.  My understanding is
that even with radar, "Nap of Earth" flying is a high workload activity.

A search of the United States' National Transportation Board's (NTSB)
Aviation
page:
http://www.ntsb.gov/Aviation/Aviation.htm
found three FADEC related helicopter crashes, and also the fact that the

FADEC itself permanently records some flight data.

The accidents are:
(1) FTW96LA395; September 21, 1996, a Bell 407 helicopter; registration:
   N1114S
(2) MIA97RA005; OCT-09-96; a Bell 407 helicopter; registration: N1117P
(3) FTW97RA055; NOV-20-96, a Bell 407; registration: ECGJC

Note the closeness of the dates and two of the registrations.

All of these crashes were considered pilot error.  Readers of this forum may
recognize a human factors risk in the interface and procedures for recovery
from FADEC failure.  From the FTW96LA395 accident report:

"According to the Bell 407 Rotorcraft Flight Manual, when the FADEC FAIL
warning light illuminates in flight, the pilot should accomplish the FADEC
FAILURE procedure as prescribed in paragraph 3-3-K.  The procedure is,
immediately retard the throttle and hold it to the 90% throttle bezel
position; maintain Nr (rotor) with collective only; depress the FADEC MODE
switch one time regardless of switch indication, FADEC will switch to MANUAL
mode 2 to 7 seconds after this action if it is not already in manual mode;
maintain Nr 95% to 100% with throttle and collective; land as soon as
possible, and perform a normal shutdown if possible. There is a warning that
2 to 7 seconds after the FADEC FAIL warnings, FADEC may be in MANUAL mode
without any pilot action.  Nr may increase very rapidly and overspeed to
110% which will result in an engine flameout unless the pilot takes
immediate manual control of the FADEC with the throttle."

The fact that FADECs have a permanent record of their data comes from the
Statement of Mike Poole to the Transportation Safety Board of Canada
speaking about the September 2nd, 1998, SwissAir MD-11 crash off Peggy's
Cove: "the FADEC from the Number 2 engine gave us data in those last six
minutes of the flight where the recorders had already stopped. So, in this
case, the non-volatile memory was extremely useful."
http://www.ntsb.gov/events/symp%5Frec/proceedings/may%5F3/sessioni/poole%5Ftranscript.htm

The procedure for recovering from failure, the risk of engine failure if the
procedure is not followed and the existence of non-volatile memory in the
Textron FADEC are confirmed by the Bell Helicopter/Textron website:
http://32.97.252.12/print/encyclopedia/407pdb/section1/page_1_123.html

A probable cause for the June 2nd 1994, RAF Chinook Flight ZD 576 crash into
the Mull of Kintyre may include a human factors risk in the interface and
procedures for recovery from FADEC failure.  This would be aggravated by a
high workload flight regime.  Data for whether or not there was a FADEC
failure should have been available in the non-volatile memory built into the
FADEC.

Mike Beims <[email protected]>

------------------------------

Date: Wed, 10 Jan 2001 09:59:59 -0800
From: "Nathan K. Pemberton" <[email protected]>
Subject: Armchair Chinook RISKS analysis is misplaced

In my opinion, the armchair analysis of the Chinook crash by RISKS
participants is a pointless exercise. The military does not operate in a
risk-free environment. They regularly take on risks which would be
unacceptable to the general public. This does not imply that they should be
absolved in cases of recklessness, but the tone of the discussions so far
seems to be alarmist. For a bunch of computer jocks to try to tell the
military its business when it comes to operations is the height of
arrogance.

For a picture of the types of risks involved in military helo ops, read the
book "Black Hawk Down" by Mark Bowden. Not having served in the military
myself, I cannot attest to its accuracy, but it was well received by
soldiers involved in the actions described. Some of the book also appears
with supplementary material on the Philadelphia Enquirer web site:
http://www.philly.com/packages/somalia/

Nathan Pemberton <[email protected]>

------------------------------

Date: Wed, 10 Jan 2001 13:08:48 -0500
From: Chris Warwick <[email protected]>
Subject: Since when is Northern Ireland considered a war zone?

Re: Chinook (O'Connell, RISKS-21.19)

The Officer in Charge has been held responsible, he/she died in the crash.
Given that the Board of Inquiry does not indicate that the aircraft was
under ground control, I presume that someone on board, likely the pilot, was
the Officer in Charge, and made the decisions that lead to the crash.

A Military Board of Inquiry is made up of both peers and superiors of the
Officer in Charge. The function of the Board is to examine all the factors
leading to an incident, and to examine whether the Officer in Charge made
correct or reasonable decisions along the way. In this case the Board has
evidence that decisions made and risks taken were NOT appropriate for the
threat environment.

The Captain usually goes down with his ship, whether he/she lives or dies is a
separate matter.

The risk is we overlook a potential cause for future problems, because this
ruling implies that the aircraft operated flawlessly.

In this case the "cause" of the accident is clear, but we may still need to
examine why the aircraft intersected the ground. If for no other reason than to
make future Nape-Of-The-Earth operation as safe as it can be...

------------------------------

Date: Thu, 11 Jan 2001 18:24:38 -0500
From: Aydin Edguer <[email protected]>
Subject: Oregon Jurors summoned for 1901

In Multnomah County, Oregon, about 3000 residents have been summoned to
show up for jury duty in 1901.  One person responded that he couldn't
possibly get there in time because he had not yet been born.
[Source: Michelle Roberts, *The Oregonian*, 3 Jan 2001; PGN-ed]

------------------------------

Date: Wed, 10 Jan 2001 12:14:11 -0500
From: [email protected]
Subject: Y2K bug in Millennium clock

I received one of those countdown to the millennium clocks for Christmas
1999.  It counted down the days/hours/minutes/seconds to Jan 1, 2000.  When
it reached zero, the displayed stayed at all zeros and flashed.

Everything worked great.  It has a mode function that you can get it to
count down to Jan 1, 2001 (they call this scientific mode as opposed to
celebration mode).  After New Years 2000, I set it to scientific mode and
forgot about it.  A couple of days before New Years 2001, I dug the clock
out and noticed that the count down was off by a day.  It was displaying 1
day and several hours to new years on Dec. 29th.  I figured that it had lost
a day sitting in my drawer.  When I checked the actual day (you can set it
to be just a date/time clock as well), it was correctly set to Dec. 29th.
It turns out that the date/time software/firmware correctly dealt with leap
year 2000, but the countdown code missed the boat.  It must have been hard
coded to count down to Jan 1, 2000, and then they probably added 365 days
for the count down to 2001.

My Millennium clock has a millennium bug.

Mike Palmer

------------------------------

Date: Fri, 12 Jan 2001 12:44:50 -0000
From: "'o-Dzin Tridral" <[email protected]>
Subject: Re: 54 weeks in a year? (RISKS-21.18)

Doesn't the problem of 54 weeks in a year depend on how week numbers are
calculated?

The problem of 54 weeks seems to depend on starting weeks on a Sunday and
counting Week 1 as being the week containing 1st January.  Hence in the case
of 2000 you get a Saturday fragment in Week 1, 52 Weeks running Su-Sa, and a
Sunday fragment in Week 54.

The web page http://www.year2000.com/y2kcurrent1.html appears to make these
assumptions.

The ISO standard for dates and times (ISO 8601) works differently by
starting weeks on a Monday (that's not the important bit) and making Week 1
of a year the week containing the first Thursday.  Hence week 1 of 2000
began on 2000-01-03 and the preceding Saturday and Sunday belonged to Week
52 of 1999.

I've tried to find year that has 54 weeks using the ISO definition, but
failed.

The standard is at http://www.iso.ch/markete/8601.pdf and there are useful
links from http://www.egroups.com/group/iso8601

I think that this standard becomes ever more important now that we're in the
low year numbers of the century.  We'll look back on dates like 03/05/02 and
wonder what on earth it means, given the YY/MM/DD, DD/MM/YY, MM/DD/YY (and
other) possible interpretations.

I hope this doesn't prove to be a week argument and that people will be
encouraged to make a date with a standard.

'o-Dzin Tridral, Senior Computer Officer, UIS, Cardiff University, PO Box 78
CF10 3XL +44 29 2087 6160   [email protected]  W http://www.cf.ac.uk

------------------------------

Date: Thu, 11 Jan 2001 12:43:35 +0100
From: Paul van Keep <[email protected]>
Subject: Re: 54 weeks in a year? (RISKS-21.18)

PGN wrote: The year 2000 began on a Saturday and ended on a Sunday; ergo, 54
calendar weeks.

It is highly unlikely that week numbering was part of the cause [of the
Norwegian anomaly].  Norway and the rest of Europe adheres to a different
definition of the week than the US, where the week starts on Monday. There
is also an ISO spec that defines week numbering.  That spec states that week
1 of a year is the first week that has at least 4 days in that year.  So if
the year starts on a Friday, Saturday or Sunday, those first days still
belong to the last week of the year before.  If we look at 2000, the first
two days are week 52 (they are part of the last week of 1999) and 31
December is exactly the last day of week 52 of the year.

Paul van Keep

 [But some people use U.S. calendar software written by non ISO-aware
 folks!  PGN]

------------------------------

Date: 26 Dec 2000 (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 20" for volume 20]
http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
   http://www.csl.sri.com/illustrative.html for browsing,
   http://www.csl.sri.com/illustrative.pdf or .ps for printing

------------------------------

End of RISKS-FORUM Digest 21.20
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.