[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Timezones offset by non-integral hours
- To: Common-Lisp@SU-AI.ARPA, decvax!mulga!bruce.csirovlsi@UCB-VAX.ARPA, bug-lispm@SCRC-RIVERSIDE.ARPA
- Subject: Timezones offset by non-integral hours
- From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
- Date: Mon, 13 Aug 84 00:56 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12036679738.BABYL@CMU-CS-C.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
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
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
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!