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

[Marc Feeley <feeley@x>]

On 2010-11-28, at 1:13 PM, John Cowan wrote:

> Marc Feeley scripsit:
> 
>> (alarm (+ (now) (year->seconds 1)))
> 
> The year->seconds procedure makes no sense, because you need to know if
> this is leap year or not, and whether we are talking Gregorian or Julian
> leap years.  This is a fine example of the need for broken-out time.

The problem is that a "date" is just a label for a point in time.  A label assigned by humans in a rather arbitrary way that can't even be determined ahead of time (leap seconds, time zones, etc).  It is quite a shock to think that our "date" labelling system isn't even one-to-one with time points (for example, on the US east coast, there are two points in time that correspond to 1:30 AM November 7, 2010, because at 2 AM November 7, 2010 the clocks are set back to 1 AM to return to Standard Time).

So if one wants to refer to a future point in time, using a "date" only makes sense for synchronization with a human activity (say "wake me up an hour before I need to be at work next monday").  In process control situations it is really time intervals and time points that are required (if you want to reheat leftovers for 10 minutes in your microwave at 1:59 AM November 7, 2010, you want the microwave to heat for 10 minutes, not 70 minutes, or 70 minutes +/- one leap second).  Using dates for process control is madness.

I want to make sure that the date and time abstractions are not hopelessly intertwined.  The thread/process scheduler of an OS should work with time points.  A calendar application should work with dates.

Marc


_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@x
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss