[decvax!mulga!bruce.csirovlsi: Apparent Commonlisp stupidity]

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

Date: Fri, 03 Aug 1984 06:29:00 -0000
From: decvax!mulga!bruce.csirovlsi at Berkeley
Re:   Apparent Commonlisp stupidity
Apparently-To: fahlman@cmu-cs-a.arpa

Scott,

Please pass this on to the right forum.  I think you'll find it sensible.

On page 444 of "Common Lisp," the representation of timeZone in decoded time
is defined as an integer specifying the number of hours west of GMT. However,
significant parts of Australia and PNG are at +10:30, ie, on a half-hour
boundary.  Further, other parts of Australia, and some Pacific nations, are on
15 and 20 minute boundaries.  Finally, at one time Tonga was +12:19:12, so
that "The sun rose first on Tonga" and so that sol was directly and precisely
overhead (on the mean) at noon. 

This is no laughing matter.  If Arpa standards have defined Commonlisp's
definition of timeZone, then we can blame them when a Commonlisp-based
early-warning system at Pine Gap causes a launch-on-warning attack 1/2 hour
before the Pentagon is notified.  (Pine Gap, near the Alice, and Exmouth, on
the Northwest Cape, are America's two shoot-first, ask-later bases in Oz.) No,
I don't think this would really happen.  But unless Arpa has constrained the
definition, I think that Commonlisp's developers need to review timeZones
using global time considerations.  Perhaps what is needed is a formal zone
name (integers fine; characters better) and also the local offset
(hrs:mins:secs). 

Closer to reality, DEC's Commonlisp implementation will soon be running in a
place with a half-hour offset. It will necessarily lie about its zone, and
this will make it impossible to compute time differences properly.  (Consider,
for example, that the EST in this message is Australian, not Yank.)  For comic
relief, we can note that VMS is sucking even more air than usual here, as it
STILL has no notion of zone or offset after six brain-damaged years. 

On a lesser note, I believe that decoded time should include dayOfYear,
weekOfYear, and leapYearP, because they were necessarily computed (or already
available) to decode UT.  Be complete and consistent when there's no extra
cost, eh?  Also, I find that, in EncodeUT and DecodeUT, the treatment of
daylight time and (local and other) zones is inconsistent. 

Despite the occasional levity, Scott, my tone is serious.  It's easy to be
parochial about time when there's three hours difference in an essentially
closed world.  Living outside the US has given me tremendous insight here. 

I'm ready for flak, but you'll miss unless you shoot on the half-hour.

			Cheers,

			Bruce (Nelson)