[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [r6rs-discuss] [Scheme-reports] Date and time arithmetic library proposal for R7RS large Scheme

On 2010-11-28, at 11:53 AM, Per Bothner wrote:

> On 11/27/2010 06:17 PM, Ray Dillinger wrote:
>> If we treat the cesium standard as the preferred unit for seconds,
>> then we are true to the SI standard for seconds, but there are two
>> downsides.  ... The major one is that
>> we cannot get the local time corresponding to a numbered second
>> more than a year in the future, nor the numbered second corresponding
>> to a specified date and time more than a year in the future.
> I can imagine wanting seconds to have a fixed length, and wanting to
> correct for leap-seconds when dealing with times in the past or immediate
> future (e.g. when setting a timer to record a program tomorrow).
> I can't imagine needing second-level precision for times more than a
> year in the future.
> E.g. if I set an alarm to go off 2 years in the future, I'm willing to
> risk that it rings a second or two later or earlier than expected.
> (If the alarm is set to go off at a specific time, the duration might
> be longer than expected.  If the alarm is set for a specific number of
> seconds, then it might go off at an earlier time than expected.)
> As long as the specification is clear, I think that is OK.

I agree for single events, but not when there are several close events to be scheduled far in the future.

For example, turning on an alarm a year from now, and also turning it off 5 seconds later.  You want to be able to do something like this:

(define (alarm when)
  (sleep-until when)
  (sleep-until (+ when 5))

(alarm (+ (now) (year->seconds 1)))

Which is better than:

(define (alarm when)
  (sleep-until when)
  (sleep-until (+ (now) 5))

because the second way will give a delay slightly longer than 5 seconds (depending on how long (turn-on-alarm) takes).


r6rs-discuss mailing list