Status: Passed v1 (as amended in v2) Mar-89 by 18-0 vote.
References: Section 25.4.1 (Time Functions) (p. 443-444)
Edit history: 1-Mar-89, Version 1 by Chapman
10-Apr-89, Version 2 by Pitman (amendments per X3J13)
CLtL states that the time zone part of Decoded Time is an integer.
However, it is possible to have a non-integer time-zone.
Specify that the time zone part of Decoded Time is
1. a rational number (either an integer or a ratio)
2. in the range -24 to 24 (inclusive on both ends)
3. a multiple of 1/3600.
1. For CL to accommodate all possible time designations, it is
necessary to allow time zone to be non-integer. Some places
in the world are on half-hour or quarter-hour times.
There is no demand for floating point time zones. Since such
zones would introduce inexact arithmetic, we did not consider
adding them at this time.
2. This prohibits the perverse use of very incredibly time zone
magnitudes to get around the year restriction on times
in portable code.
3. This requires time zones to be represented as even multiples
of 1 second.
VAX LISP allows time zone to be non-integer.
Cost to Implementors:
Very slight. Implementations which use integer-only arithmetic
in dealing with time zones might have to switch to a more generic
kind of arithmetic.
Cost to Users:
Depends on situation. Very slight negative to very strong positive
effects will be seen by users.
In some cases, this legitimizes time zones which are already a
political necessity and may make life easier for users.
In at least one known case, this will make things a little harder
because `very large' time zones will not be permitted. However,
such time zones probably were not really portable to begin with
so this is more just a recognition of the status quo.
In most cases, no user code will have to be modified.
In the one known case using `very large' time zones, the user may
have to write his own time manipulation software if he really wants
to be portable.
Probably slightly improved.
Haflich was claiming he might want to use very large negative time zones
to go back in history beyond 1900 (where universal times supposedly
bottom out). However, most implementations probably don't represent the
shifts in calendar system which occurred at various points before that
time, most implementors present at the Mar-89 meeting seemed to think this
`hack' was probably not really going to work portably anyway.