> From: John Cowan <co...@mercury.ccil.org>
> Cc: disc...@r6rs.org, b...@sonic.net
>
> r6rs...@free-comp-shop.com scripsit:
>
> > One thing I insist upon is that the clock never go backward.
>
> No matter how mis-set it is?
Of course not. If it breaks fix it.
I mean the standard should not require the
clock to go backward in normal operation.
> > ... calendrical time is a real number, while the
> > sub-second, physical time is an integer. I think
> > this is exactly backward.
> On reflection I agree
(Silence)
> I see no reason to make the epoch implementation-
> dependent.
On reflection I agree. I was hoping to have one fewer
thing to disagree about, and to make it easier to move
the epoch at the end of an era, but we want to say:
(define (utc time leap)
(let* ( (ss (mod time 60))
(m (div time 60))
(mm (mod m 60))
(h (div m 60))
(hh (mod h 24)) )
(list hh mm (+ ss (or leap 0)))))
and this requires that the epoch be midnight of some
day. That rules out J2000.0, which is indeed a most
sacred instant, but somewhat odd on the Gregorian
calendar.
Since the epoch does not matter much, let it be 1970.
> > utc
> > The universal time count corresponding to this date.
> > This field is required in every date. It is an integer.
>
> It would be very confusing for UTC to refer to
> anything but Coordinated Universal Time.
I thought it was a good pun, but it _is_ Coordinated
Universal Time, expressed as a single integer. Its
main purpose was to have something to contrast to
posix-time, but if posix-time is to be an integer, then
there is not much to distinguish.
I withdraw the suggestion.
> > Why must the number of jiffies per second be an integer?
>
> On the assumption that there is at least one jiffy
> per second, there is no reason for it not to be an
> integer. If your clock ticks at 37.5 Hz, then set
> jiffies-per-second to 75 and increment current-jiffy
> by 2 at each clock tick.
It will get messy if the clock ticks at (sqrt 20000) Hz.
Whether it is better to have integer jiffies or
real seconds, I am not so sure. It's not Wrong.
> > (current-elapsed-time)
> >
> > A real number giving the time in SI seconds since
> > the epoch.
>
> Equivalent to (/ (current-jiffy) (jiffies-per-second)).
Whatever.
> > (epoch-of-elapsed-time)
> >
> > The utc second during which the current elapsed
> > time was 0.000.
>
> I don't want to assume that implementations can supply this.
I still think it would be good to have a standard way
to get this information, since it is needed to relate
the Calendar time to Physical time.
But I would vote for it as now written.
-- Keith
_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
