CLHS: Issue TIME-ZONE-NON-INTEGER Writeup

#

## 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.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.