Some quick responses to quick comments.

> -----Original Message-----
> From: Marc Feeley [mailto:xxxxxx@IRO.UMontreal.CA]
> Sent: Monday, March 13, 2000 12:24 PM
> To: srfi-19@srfi.schemers.org
> Subject: leap seconds
>
>
> After a very quick look at SRFI-19 I have the following comments:
>
> 1) The interface assumes that there are exactly 86400 seconds in a
> day.  This is not true.  There can be exactly 86399, 86400 and 86401
> seconds in a day, due to "leap seconds".  Note that the point in time
> where the leap seconds are added (or removed) is under the control of
> a committee and there is no deterministic algorithm to determine in
> advance where they occur (it all depends on the speed of rotation of
> the earth which varies slightly, up and down, due to various factor).
> So the "seconds" component should be in the range 0-60 inclusive.
> According to "man ctime" under linux, the seconds field can go up to
> 61, but I don't understand why that high.  You should probably
> research this a little more.  Here are some interesting sources of
> information:
>
>    http://tycho.usno.navy.mil/leapsec.990505.html
>    http://www.naggum.no/lugm-time.html
>

It doesn't assume this many seconds in a year; it defines this many
seconds in a year. One advantage is that you get a deterministic
algorithm (as you say). Another important advantage is that you can
treat time as a number, and use standard mathematical operators. The
disadvantage is that drift from UTC, as you say.

> 2) To be consistent with Scheme naming convention and practice, you
> should rename "get-universal-time" to "current-time",
> "current-universal-time", or "current-date".
>

Sorry, I missed the last Scheme Naming Convention--when was it held?
Seriously, I don't have a problem changing the names, but perhaps you
could point out a "here's how to name Scheme procedures" document; I'd
appreciate it.

> 3) Why limit the resolution of the time datatype to 1 second?
> The resolution should be implementation dependent, and if you insist,
> of at least 1 second resolution.  This is so that an implementation
> can use the time datatype for finer resolution timing (such
> as a "(thread-sleep! wakeup-time)" procedure I am considering for
> my thread SRFI).  Otherwise, to do finer resolution timing you need
> another time datatype, and this is rather clumsy.
>

The main reason is just that bug-a-boo of mine to be consistent with
Common Lisp; I'll reconsider this. I've found the CL approach clumsy in
just this way.

> 4) I don't like the fact that the "year" component has a special
> meaning between 0 and 99:
>
>     Year, an integer representing the year C.E. (i.e., A.D.). If the
>     integer is between 0 and 99, however, it represents the current
>     year + the year (if it is less than 50) or the current year - the
>     year (if it is greater than or equal to 50).
>
> This is because the meaning of a date created with
> encode-universal-time will depend on the time when that procedure was
> called, and since there is no way to know precisely at what time it
> was called there are (extreme) situations where the time meant is
> not clear (i.e. meaning of year 50 at the turn of the year 2000 plus
> or minus a few nanoseconds may be 1950 or 2050).
>

More Consistency With Common Lisp (CWCL). Still, I'm willing to drop
this.

> 5) Instead of the "multiple value" interface of decode-universal-time
> I prefer single-value accessors of the kind:
>
>   (universal-time-second ut)
>   (universal-time-minute ut)
>   ...
>
> and also (universal-time-second ut) would return a real, possibly
> inexact.
>

Maybe. Perhaps you could give me reason beyond 'I prefer'?

> 6) Why use 1-1-1900 as a base, why not 1-1-1970 which is the norm
> under UNIX?  I know this is a convention, but a closer base date gives
> more implementation leaway... for example a 2 fixnum representation
> (32 bit words, 3 tag bits) counting nanoseconds since 1-1-1900 will
> wraparound in 1991 but if you count from 1-1-1970 it will wraparound
> in 2061, which is probably reasonable for many applications.  And if
> you insist on 1-1-1900, please consider 1-1-2000 at least.
>

Again, CWCL. 1-1-2000 seems like a poor choice because time isn't
defined before this number. 1-1-1970 might be fine.

> 7) The time datatype should be abstract, i.e. it shouldn't be
> a number.  There should be conversion functions between time and
> seconds since the base time:
>
>   (universal-time->seconds ut)
>   (seconds->universal-time secs)
>
> Note again that the result of universal-time->seconds and the
> argument of seconds->universal-time should be a real, possibly
> inexact.
>

The main reason is insist that it be a number is one can use standard
mathematical operators on them, without converting. You don't need a
special time>, etc.

>
> [Useful implementation notes snipped]
>
> Marc
>

I think the most crucial question Marc's note raises is whether time
(especially 'universal time') should be an abstract data type or a
number; and, if a number, whether it should be a real or an integer. I'd
be glad to hear others' ideas.