Timezones offset by non-integral hours

["David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>]

    Date: Sat, 4 Aug 1984  02:56 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    Date: Friday, 3 August 1984  02:29-EDT
    From: decvax!mulga!bruce.csirovlsi at Berkeley
    Re:   Apparent Commonlisp stupidity

    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. 

I believe that Common Lisp ought to allow the timezone to be a non-integral number
of hours, accepting either a floating-point number or a ratio, as our implementation
does.

BUG-LISPM: Too bad this doesn't actually work in our implementation!
The code looks like it used to work, and then someone "improved" the
code for TIME:DECODE-UNIVERSAL-TIME-WITHOUT-DST to try to avoid excess
consing by using fixnum-specific operations.  We need to fix this.

    ...Perhaps what is needed is a formal zone
    name (integers fine; characters better) and also the local offset
    (hrs:mins:secs). 

We have some approximation to this, which has succeeded in convincing me
that the world is not in sufficient agreement on names of timezones to justify
enshrining any particular set of names in a standard language specification.

    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?  

I have no particular opinion about this.

	       Also, I find that, in EncodeUT and DecodeUT, the treatment of
    daylight time and (local and other) zones is inconsistent. 

I agree and have already complained to Guy about this.  I suspect it's just
typographical errors in the manual, but he didn't reply to my queries.

When we're done with this discussion we can address parameterization of the dates
when daylight savings time turns on and off!