[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.