Scheme language standardization process
Marc Feeley scripsit: > 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). Quite so, which is why I have both instants and date objects. > 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). Hence the existence of the daylight-savings-time field and its C analogue, the dstflag. > 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. Correct. And it's a calendar API I'm proposing. -- John Cowan cowan@x http://ccil.org/~cowan The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street. _______________________________________________ r6rs-discuss mailing list r6rs-discuss@x http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss