Subject: RISKS DIGEST 17.84

RISKS-LIST: Risks-Forum Digest  Tuesday 5 March 1996  Volume 17 : Issue 84

  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, etc.       *****

 Contents:
Information on the B757 Birgen Air Accident (Peter Ladkin)
Spamming, filtering, S/N, Gresham's Law and the net (Richard Cook)
Interesting bug in Netscape (Art Delano)
Re: Java (E. Larry Lidz)
CERT Advisory CA-96.05 - Java [abridged] (CERT)
Telephone exchange "collapses" following bombing (Jake Livni)
More on Excel and leap days (Geoffrey Cooper, Carl Hauser)
Re: Daylight Savings Time (Edward R Anderson)
Re: WIN95 Daylight saving (Steve Elliott, David Morgan)
Re: Another Intel chip flaw (Joseph Richardson)
Yet another type of leap-year bug: restart risks (Otto Stolz)
Re: 2000 IS A LEAP YEAR! (Dale Robinson)
Re: Leap year arithmetic (Barry Jaspan, Jan Vorbrueggen, Gary Koerzendorfer,
   Brian T. Schellenberger, Wayne Hayes, Stephen Thorsett)
ABRIDGED info on RISKS (comp.risks)

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

Date: Tue, 5 Mar 1996 11:54:33 +0100
From: [email protected]
Subject: Information on the B757 Birgen Air Accident (RISKS-17.82)

I talked with Alan Pollock at the National Transportation Safety Board in
Washington DC on March 4. The investigation is being conducted by Dominican
Republic with `full participation' of the US NTSB. The Dominican Republic
civil aviation authorities asked the NTSB to make available some information
after a preliminary review of the Cockpit Voice Recorder (CVR) and Flight
Data Recorder (FDR) information.

[Summary of official information]

The CVR and FDR were taken to the NTSB on February 28th. A preliminary review
was conducted on February 29th. The quality of the data was good. The crew
discussed airspeed indications early during the takeoff roll and after takeoff.
While climbing through 7300ft, the stick shaker sound was heard, the
aircraft started to descend and the stick shaker sound continued for about
84 seconds until the end of recorded data. Recorded airspeed at stick shaker
activation was 335kts. Ground-based radar and other FDR data indicated a much
lower airspeed. The data are consistent with proper functioning of flight
controls, engines and thrust reversers. There is no evidence of any unusual
weather event or external forces on the aircraft. Investigation is continuing.

[end of summary]

The `stick shaker' is a device which `shakes' the control stick when lift
begins to degrade to let the pilots know of an impending aerodynamic stall.
It really gets your attention, quickly, not to speak of raising the
adrenaline level.

Courtesy of Robert Dorsett, I understand there are three independent airspeed
indication systems in the B757: two electronic and one mechanical backup.
It's unlikely in the extreme that all three were faulty.  Pilots are trained
to deal with faulty information (I've had an airspeed indicator fail, I had
only one system, I'm not a professional pilot). Since controls were
functioning normally and there was no indication of outside disturbance,
I would think it's likely that there was no relevant airfoil contamination or
misfunction. One could further conclude from this that the recorded 335 knots
is likely not the actual airspeed at time of stick shaker activation.

This raises two issues which will presumably be addressed by further inquiry.
First, why did airspeed drop: is it because the pilots appeared to be
following faulty airspeed information; if so, why were they doing so?
Second, was recovery initiated by the pilots at stick-shaker activation:
if not, why not; if so, was 7300ft altitude sufficient to recover in the
actual situation, or did other factors inhibit recovery? Answers to these
questions will probably lead to other questions.

The full text of the February 7 FAA press release and the March 1 Dominican
Republic Factual Information from the NTSB is contained in my compendium
`Computer-Related Incidents and Accidents with Commercial Airplanes' at
          http://www.techfak.uni-bielefeld.de/~ladkin/
(The name of the compendium changed since the scope is broadening somewhat.)

Peter Ladkin

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

Date: Tue, 5 Mar 1996 08:33:08 -0600
From: [email protected] (Richard Cook)
Subject: Spamming, filtering, S/N, Gresham's Law and the net (Re: RISKS-17.83)

I have made the claim that the nature of Internet opens it to various forms
of deliberate damage and also to inevitable processes of decay and stale
information.  These latter two issues are important because anything that
increases the amount of bad, stale data in the system tends to provide
incentives for more robotic programs and automated mechanisms for use in
screening. These devices have their own problems, in particular their
ability to generate large volumes of traffic which then become loads on the
system and problems for human operators to sort out.  When ill-intentioned
people are added to the mixture, it is possible to have really unpleasant
things happen.  PGN's lead item in RISKS-17.83 is a case in point.

The value of access to a data channel is partly a function of the signal to
noise ratio of the data channel.  As the S/N falls there are incentives to
use more sophisticated filters to extract signal from noise.  In analog
systems these noise filters have well defined, if often undesirable,
characteristics.  In the digital realm, the behavior is more difficult to
characterize, especially when the filter design is closely matched to
expected nature of the signal being filtered.

The growing use of these filters necessarily marks the Internet as a
thermodynamically inefficient process: it is always less efficient to filter
after the fact than it is to clean the signal before.  (The problem, of
course, is that those who bear the cost of filtering at the tail end are not
those who would bear the cost of producing a really clean signal at the
front end!)

Of course, the net has been successful to date largely because the
information placed there has been of known quality and those involved with
the network have been restrained by storage limits, the originating group's
culture, etc.  In this way there has been a historically high S/N, which
makes searches and conversations relatively low effort and high yield.

The English economist Gresham's name is attached to a "law" of monetary
systems that says "Bad money pushes good money out of circulation."  Bad
money refers to paper currency, which is easily debased by printing more.
Good money refers to coin minted from precious metals, the value of which
remains relatively constant.  When paper currency is debased, people tend to
hoard their coin and the paper circulates, hence the law.

I modestly propose Cook's law (named after my Mother) which is "Bad data
drives good data out of circulation."  Here the bad data is the easily
collected, easily stored, largely meaningless collections of characters that
we see in so many areas (e.g. medical records) that are making the value of
effortful contributions (e.g. thoughtful summaries of the relevant details
of a patient's clinical history and current state) hard to find.  I claim
that they are hard to find in part because the other things in the chart
constitute a form of noise that makes extracting the signal hard, and in
part because the value (and incentive) for creating them is largely lost in
the blizzard of other material.  Interestingly, the electronic medical
record has been accompanied, in many places, by an underground paper system
that isolates relevant information from the electronic data in ways that
make it easy to generate and retreive, at least in the context of daily
activity.  We see this especially in the ICU and operating room where
informal records are made on slips of paper, pieces of adhesive tape, etc.

As the electronic medical record accumulates more data there will be a major
effort to raise the S/N level via information filters not unlike the robotic
devices now being developed to cope with the falling signal and rising noise
levels of the Internet.  Humans will attempt to isolate high signal-low
noise areas by using manual paper methods and hoarding the paper and by
constructing within the electronic environment, vaults with access that is
economically or organizationally restricted to those with incentives to
maintain high S/N.

Richard I. Cook, MD ............. Cognitive Technologies Laboratory
Department of Anesthesia and Critical Care ** University of Chicago

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

Date: Tue, 5 Mar 1996 11:25:52 -0500
From: [email protected] (Art Delano)
Subject: Interesting bug in Netscape

As a Macintosh user and Netscape user, I've been waiting anxiously for an
implementation of Java for the Mac. Netscape finally released their beta 1
version of their browser with Java implementation about ten days ago, and
like all fans of bleeding-edge technology, I downloaded my copy the moment I
heard about it. There are many problems that can be attributed to such an
early version of the program, I noticed one particularly grievous oversight:
the lack of a provision to turn Java downloading off.

Volunteer Beta testers have to be willing to deal with many problems, but
being unable to evade such a well-documented and easily avoidable security
risk shouldn't be one of them. I hope this is a problem that Netscape fixes
in their next beta release.

AjD   [email protected]   http://www.frymulti.com/~adelano/

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

Date: Tue, 5 Mar 1996 11:08:11 -0600 (CST)
From: "E. Larry Lidz" <[email protected]>
Subject: Re: Java (RISKS-17.83)

Netscape and possibly other (future?) Java-enabled browsers do not allow for
system-wide defaults.  They should allow for System Administrators to not
only set defaults for users, but to also override user preferences.  This
would allow the Administrator for a system to disable (for example) Java or
JavaScript system wide.

The risks in not having such an option?

Assuming Java is bullet-proof.

Java is the type of program that has potential security holes in it as
it allows someone to run programs on a machine they do not necessarily
have any real access to.  It is well designed to reduce the risks, but
like any new program, there are bound to be bugs.

Patches are nice, but there is no way to insure that everyone would be
running the new version.  If the browser allowed preferences based on
version number, one could disable Java for buggy versions, but allow it for
patched versions.

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

Date: Tue, 5 Mar 1996 13:34:09 -0500
From: CERT Advisory <[email protected]>
Subject: CERT Advisory CA-96.05 - Java [abridged]

Topic: Java Implementations Can Allow Connections to an Arbitrary Host

The CERT Coordination Center has received reports of a vulnerability in
implementations of the Java Applet Security Manager. This vulnerability is
present in the Netscape Navigator 2.0 Java implementation and in Release 1.0
of the Java Developer's Kit from Sun Microsystems, Inc. These
implementations do not correctly implement the policy that an applet may
connect only to the host from which the applet was loaded.

The CERT Coordination Center recommends installing patches from the vendors,
and using the workaround described in Section III until patches can be
installed.

As we receive additional information relating to this advisory, we
will place it in
 ftp://info.cert.org/pub/cert_advisories/CA-96.05.README

We encourage you to check our README files regularly for updates on
advisories that relate to your site.

I.   Description

    There is a serious security problem with the Netscape Navigator 2.0 Java
    implementation. The vulnerability is also present in the Java Developer's
    Kit 1.0 from Sun Microsystems, Inc. The restriction allowing an applet to
    connect only to the host from which it was loaded is not properly
    enforced. This vulnerability, combined with the subversion of the DNS
    system, allows an applet to open a connection to an arbitrary host on the
    Internet.

    In these Java implementations, the Applet Security Manager allows an
    applet to connect to any of the IP addresses associated with the name
    of the computer from which it came. This is a weaker policy than the
    stated policy and leads to the vulnerability described herein.  [...]

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (FIRST).  [...]

  CONTACT [email protected]     +1 412-268-7090 (24-hour hotline)
  Location of CERT PGP key: ftp://info.cert.org/pub/CERT_PGP.key
  CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are
  on call for emergencies during other hours.  Fax +1 412-268-6989

  CERT Coordination Center, Software Engineering Institute
  Carnegie Mellon University, Pittsburgh PA 15213-3890 USA

To be added to our mailing list for CERT advisories and bulletins, send your
email address to [email protected]

CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
ftp://info.cert.org/pub/

CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce

Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.

CERT is a service mark of Carnegie Mellon University.

  [See full CERT bulletin for further details.  PGN]

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

Date: Tue, 5 Mar 1996 09:49:24 -0500
From: [email protected] (Jake Livni)
Subject: Telephone exchange "collapses" following bombing

Following the suicide bombing in Tel-Aviv, Israel yesterday, the local
telephone exchange was reported to have "collapsed" due to overload.  In the
report I heard, "collapse" was not defined.

To better understand this, it is helpful to know that Israelis are acutely
aware of goings-on.  Israelis are major users of cellular telephones;
terrorist attacks are reported nation-wide literally within minutes.

I was in Jerusalem last week, very near 2 terrorist attacks.  After the
first, friends and relatives called from out of town, recognizing that I was
nearby, to inquire if all was well.  The following day, I went into town,
boarding the bus exactly when another terrorist attack occured at a nearby
intersection.  As usual, it was reported on the radio within minutes, while
I was still on the bus.  I got off two stops later and used a public pay
phone to call my home-base, to notify them that I was OK.

I'm not a telephony expert, but with such `social conventions', it is
conceivable that a major telephone exchange can collapse by overloading.

Jake Livni  [email protected]

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

Date: Tue, 05 Mar 1996 12:11:10 -0800
From: Geoffrey Cooper <[email protected]>
Subject: More on Excel and leap days (RISKS-17.83)

> Excel version 5.0 on the PC does work for 2/29

This is true.  And Excel version 5.0 knows that the year 2000 is indeed a
leap year (see RISKS-17.83).  It is very clever.  Actually, it also "knows"
that the year 1900 was a leap year.  But it wasn't...

The program also doesn't appear to handle dates that are not in the 1900's or
2000's, so I couldn't check 2/29/1800 or 2/29/2100 or 2/29/2400.  Of course,
we'll all be using stardates by the time the year 2400 comes around.

- Geof

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

Date: Tue, 5 Mar 1996 10:28:15 PST
From: [email protected]
Subject: More on Excel and leap days

In each version of Excel that I've examined, the 60th day of the calendar is
29 Feb 1900. Set a cell's format to "date" and type in 60 to see for
yourself.  This means, of course, that computations such as "number of days
between x and y" where one or the other date is in early 1900 will be wrong.
Fixing the bug is also RISKy because that would change the date
interpretation of all ordinal dates greater than 59, in turn making every
existing spreadsheet involving a date compute or display something
unintended. Thought experiment: would YOU fix this bug if Excel were your
product? How?

-- Carl Hauser

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

Date: Tue, 05 Mar 96 10:23:00 GMT
From: "Anderson, Edward R" <[email protected]>
Subject: Re: Daylight Savings Time (Re: Elliott, RISKS-17.83)

A similar situation happened to me.  A heavily time-dependent system I wrote
and maintain utilizes a code-file library to translate between Universal
Time and the user's local time, in this case, Eastern Australia Summer Time.
A problem reported by my customer originated in the code-file library.  The
person who supports the code-file library diagnosed a bug that is triggered
by the switch from Summer (Daylight Savings) time to standard time.

"But that switch isn't supposed to happen until the end of March!"  True,
but *last* year, it happened at the *beginning* of March, and the code-file
library had not been bounced since the new parameter file, containing this
year's switch date was put into place, so it still thought the switch was on
3rd March.

I suspect a similar situation is what caused Steve's glitch.  The risk, it
seems to me, is in allowing local governments to futz around with the switch
dates on a whim, rather than setting a firm rule for when to switch.  On the
other hand, the risk may be that users expect computers (or software, or
programmers) to be able to predict with any accuracy, what various governing
bodies' decisions will be, long before those bodies even consider the
question.

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

Date: Tue, 5 Mar 1996 16:55:29 +-1000
From: Steve Elliott <[email protected]>
Subject: Re: WIN95 Daylight saving (Elliott, RISKS-17.83)

Following my previous post on the Sydney WIN95 daylight saving fault, I
today attended PC 96 (a large trade exhibition).  Microsofts stand had many
linked PCs running WIN95 & NT.  And guess what... all running 1 hour late!

I tried to get some idea of a fix for the faulty data but all I was offered
was "change the clock", "The state government changed the law after the
release" and "were looking into it"!

The risks here are that even the suppliers didn't seem to know there was a
problem!  or if they did they didn't tell themselves!

Who supplied the data for the release? Didn't they notice when the law
changed?

What about future changes?

The parameterization data sits in the WIN95 Registry as a hex string, it
seems to me that the least Microsoft should do is document the structure of
this string.

Steve Elliott, NORESE Pty. Ltd.  4, Glassop St., Balmain, NSW 2041 Australia
+61 (41) 12 608 12  [email protected]   Fax: +61 (2) 555 7911

  ["David Moss, Application Development Centre, +61-2-561-6532, DTN
  730-6532 <[email protected]> responded to Steve Elliot's earlier
  posting, observing that ``the legislation relevant to Daylight Saving
  Time in Australia has evolved faster than computer system manufacturers
  have been able to (or maybe bothered to?) implement the new rules.'']

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

Date: Tue, 5 Mar 1996 08:03:09 -0700
From: "David Morgan" <[email protected]>
Subject: Re: WIN95 Daylight saving (Elliott, RISKS-17.83)

As an Australian living in the US I can relate to Windows 95's woes.  I have
an Australian calendar sent to me each year so I can keep track of local
holidays and events such as these.

My calendar said that the changeover would be at March 3.  When I last
phoned home, I checked and found that the calendar was wrong.  The calendar
happens to be the Australian printing of the Far Side Desk Calendar.

This raises one RISK and one amusing possibility:

 Risk: The information used was incorrect in the first place and is relied
 upon by numerous sources.  The validation was done and performed correctly
 on this wrong information.  (GIGO).

Amusing Possibility: Microsoft uses a Far Side calendar for their research.

I also hope that the Australian product support for Microsoft realised what
the problem was early enough to help people.  But from the sounds of it the
detection was not early enough to provide a patch.

David Morgan, Interactive Software Engineering, 270 Storke Rd, Suite 7, Goleta CA 93117 USA  +1 (805) 685-1006 [email protected]  http://www.eiffel.com

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

Date: 5 Mar 1996 08:15:02 -0500
From: [email protected] (Joseph Richardson)
Subject: Re: Another Intel chip flaw (PGN, RISKS-17.83)

> The Orion flaw was discussed by Intel on 29 Feb 1969.

A premonition??  Or has the discussion on leap years gotten out of hand??

 [TNX. I am delighted people read RISKS so diligently.
 I received quite a few jokes on that slip-up.
 I fixed it in the ftp.sri.com archive copy,
 for future generations.  PGN]

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

Date: Tue, 5 Mar 1996 12:11:39 +0000
From: Otto Stolz <[email protected]>
Subject: Yet another type of leap-year bug: restart risks

About 25 years ago, I found a remarkable bug in the "midnight routine" of a
program designed to run continuously 24 hours a day, 7 days a week.

In the New Year's night of any leap year, this routine stored the value 29
for February in the table of month lengths (located in the main memory). The
bug: this variable was calculated two months before it was actually used; if
the program would have to be restarted (for any reason) within January or
February of a leap year, the length of February would have been reset to its
initial value, viz. 28, and the program would have produced garbage, on 29th
February.

Fortunately, this particular bug did not go into the production version of
the program; otherwise it could have remained undetected for several years.

The RISKs?

- In a program that runs for long periods, the restart behaviour has to be
 taken into consideration; you cannot assume that variables will last
 forever (i.e., beyond restart), if you don't specifically address this
 issue, in your program design.

- Design, or programming, errors relating to calendrical calculations (or
 other issues involving long time spans) may go undetected for long times,
 until it may have become rather expensive to correct them. (One example
 of this rule are the year-2000 problems, discussed here recently.)

Otto Stolz

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

Date: Tue, 05 Mar 1996 11:43:00 +0930
From: [email protected]
Subject: Re: 2000 IS A LEAP YEAR! (Re: RISKS-17.83)

    /* Peter, many apologies.  I left *not*s in where I shouldn't.
       Long held beliefs overriding new-found knowledge and fingers.
    */

  [Ah, yes, the (k)nots unravel.  To make a short story much shorter than
  the mass of messages I received on this one, Dale's message was really
  ambiguous to me and I probably added to the problems by not insisting
  that he clarify everything before running the item, and worse yet, trying
  to figure out what he *really* meant.  Digital of course had it right.
  But the IBM system User International (Issue 19, Nov. 95), reference
  does seem to have it wrong!  PGN]

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

Date: Tue, 5 Mar 96 11:43:57 EST
From: Barry Jaspan <[email protected]>
Subject: Re: Leap year arithmetic (RISKS-17.83)

I few years ago I wrote some code (for a database reporting tool) that tried
to understand time in various ways.  My conclusion was that time is a pain
in [***] to deal with in computer programs---it is always a special case.

 [Omitted discussion duplicating some of RISKS-17.83, but based
 on year = 365.2422 days.]

A 365 day year comes out .2422 days short.  Every four years, this is
4(.2422) = .9688 days short, so an extra day is added.  However, that means
that every four years is .0312 days too long.  Each 99 year period is
therefore 24(.0312) - 3(.2422) = .0222 days too long.  By omitting the leap
day every 100th year, that period becomes .2422 - .0222 = .22 days too
short.  After 400 years, that adds up to 4(.22) = .88 days too short, so an
extra day is added to make it .12 days too long.  I don't know when or if
another correction occurs.  If so, it is probably after 4,000 years,
bringing the period from 1.2 days long to .2 days short.

Barry

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

Date: 05 Mar 1996 11:14:58 GMT
From: [email protected] (Jan Vorbrueggen)
Subject: Re: Leap year arithmetic (RISKS-17.83)

 >>  [...] the length of the tropical year is 365.24219 days.  ...

I suggest:
- years divisible by   2000 _are_not_ leap years except
- years divisible by   4000 _are_     leap years except
- years divisible by  16000 _are_not_ leap years except
- years divisible by 400000 _are_     leap years.

This yields an average length-of-year as given above (365.24219 days, which
has an implied accuracy of ~0.4 seconds). While keeping to multiples of
four, hundred and 400, it would have the undesirable side effect of turning
2000 into a not-leap-year...and by the time the year 400000 comes around,
the length of the day will be longer anyway.

 >  I hope someone decides well in advance, to permit the programmers to get
 >  ready.

Seems unlikely to me.

       Jan

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

Date: Tue, 5 Mar 96 10:08:49 PST
From: Gary Koerzendorfer <[email protected]>
Subject: Re: Leap year arithmetic (RISKS-17.83)

You forgot to credit *the* authoritative source for the leap year rules -
Kernighan and Ritchie's "The C Programming Language", section 2.5, which
even gives us a code fragment. Woe be unto programmers who can't cut and
paste a couple lines off paper.  (Porting to Cobol is left as an exercise to
the reader.)

Gary Koerzendorfer, Systems Technology Division, Hewlett-Packard Co., 19447
Pruneridge Ave., Cupertino Calif 95014  [email protected]  (408) 447-4783

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

Date: Tue, 5 Mar 1996 12:00:09 -0500
From: "Brian T. Schellenberger" <[email protected]>
Subject: Re: Leap year arithmetic (RISKS-17.83)

In C, rendering of the formula is:

leap_year = (year % 4 == 0 && !(year % 100 == 0 && !(year % 400 == 0)));

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

Date:   Tue, 5 Mar 1996 16:35:16 -0500
From: Wayne Hayes <[email protected]>
Subject: Re: Leap year arithmetic (RISKS-17.83)

For posterity, here is (correct!) C code to compute whether "y" is a leap
year or not.  As PGN notes, this will have to change sometime probably in
the next 10,000 years to account for the 3 day/10,000 year discrepancy.  I
don't have a reference for this, but I did do copious literature checking a
few years ago when I was frothing at the mouth about this subject.  I
suppose you could count me as an expert because, (a) I'm an astronomer, and
(b) I worked at a Planetarium and this was one of the relatively common
questions asked, that our staff needed to know the correct answer to.

The more understandable version of the code comes first.  Note that it is
easiest to start with the *longest* periodicity, i.e., the 400 year one, and
then move down to the smaller period cases.  This ensures the longest period
ones don't get lost in the "if it's mod 4" case.

 typedef unsigned char Boolean;
 enum _boolEnum { false=0, true=1};

 Boolean IsLeapYear(int y)
 {
   if(y % 400 == 0) return true;
   if(y % 100 == 0) return false;
   if(y % 4 == 0) return true;
   return false;
 }

The more compact macro version is:

 #define ISLEAPYEAR(y) ((y) % 400 == 0 || ((y) % 100 != 0 && (y) % 4 == 0))

Finally, note that if you are really lazy and willing to put off your buggy
software for another 100 years, since 2000 is a leap year, then you can use

#define CHEAP_LEAP(y) ((y) % 4 == 0)    /* fix before 29 Feb, 2100 */

between 1 Jan 1901 and 31 Dec 2099.

 [Actually, because 2100 is *NOT* a leap year, it better be fixed before
 the end of 28 Feb 2100.  The above code is correct; the comment is
 misleading.  Note added in archive copy, inspired by a message from Wayne,
 15 Jul 1997.  PGN.]

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

Date: Tue, 05 Mar 1996 15:57:05 -0500
From: Stephen Thorsett <[email protected]>
Subject: Re: Leap year arithmetic (RISKS-17.83)

You may have heard enough on this topic, but the Explanatory Supplement to
the Astronomical Almanac (ed P. Kenneth Seidelmann, US Naval Observatory,
1992) [...] notes the problem raised by PGN in RISKS-17.83 -- that
eventually adjustments will be needed -- and states that although various
such adjustments have been proposed, none has been instituted.  It also
raises the interesting point (in section 12.13) that the U.S. legal code
specifies no official national calendar.  Our use of the Gregorian calendar
stems from a 1751 Act of Parliament of the U.K.

Steve Thorsett  Physics Dept  Princeton University

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

Date: 27 February 1996 (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) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  [...]
DIRECT REQUESTS to <[email protected]> (majordomo) with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
  INFO     [for unabridged version of RISKS information]

CONTRIBUTIONS: to [email protected], with appropriate,  substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, nonrepetitious, and without caveats
on distribution.  Diversity is welcome, but not personal attacks.  [...]
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
By submitting an item that is accepted for publication in RISKS, the author
grants permission for unlimited noncommercial public distribution and
redistribution in electronic and print form.  Relevant contributions may
appear in the RISKS section of regular issues of ACM SIGSOFT Software
Engineering Notes or SIGSAC Review.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks

RISKS ARCHIVES: "ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.  [...]
[Back issues are in the subdirectory corresponding to the volume number.]
  Individual issues can be accessed using a URL of the form
    http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
    ftp://ftp.sri.com/risks

PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest,
  see the unabridged INFO file at RISKS-Request (send one-line message INFO
  to [email protected] as noted above).

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

End of RISKS-FORUM Digest 17.84
************************

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.