Scheme language standardization process
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) (turn-on-alarm) (sleep-until (+ when 5)) (turn-off-alarm)) (alarm (+ (now) (year->seconds 1))) Which is better than: (define (alarm when) (sleep-until when) (turn-on-alarm) (sleep-until (+ (now) 5)) (turn-off-alarm)) because the second way will give a delay slightly longer than 5 seconds (depending on how long (turn-on-alarm) takes). Marc _______________________________________________ r6rs-discuss mailing list r6rs-discuss@x http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss