Issue TIME-ZONE-NON-INTEGER Writeup

Status:       Passed v1 (as amended in v2) Mar-89 by 18-0 vote.

Issue:        TIME-ZONE-NON-INTEGER

References:   Section 25.4.1 (Time Functions) (p. 443-444)

Category:     CLARIFICATION

Edit history: 1-Mar-89, Version 1 by Chapman

	      10-Apr-89, Version 2 by Pitman (amendments per X3J13)


Problem Description:


 CLtL states that the time zone part of Decoded Time is an integer.

 However, it is possible to have a non-integer time-zone.


Proposal (TIME-ZONE-NON-INTEGER:ALLOW)


 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.


Rationale:


 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.


Current Practice:


 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.


Benefits:


 See Rationale.


Conversion Cost:


 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.


Aesthetics:


 Probably slightly improved.


Discussion:


 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.