Scheme language standardization process
On Sat, 2010-11-27 at 12:05 -0500, Marc Feeley wrote: > On 2010-11-26, at 9:00 PM, John Cowan wrote: > > > Marc Feeley scripsit: > > > >> Please don't count time using milliseconds. It clutters my brain to > >> have to remember a different unit of time than plain seconds. > > > > And yet the SI unit of mass is the kilogram. But I'll think about that. > > I'm not sure why you bring kilograms into the discussion. We're talking about time and the SI unit for time is the second. FWIW, I agree that the unit of time should be seconds, and that it should be counted with a limited-precision "real" number. I am perfectly happy to get milliseconds, etc, as non-integer real numbers. I am also reasonably willing to allow implementations to provide clocks that are no more accurate or precise than the system clock on the local computer. But then we get to hard questions about the specifics of what "seconds" that number does represent or ought to represent. Probably the biggest issue is do we or don't we want to ignore leap seconds? If we treat each day of the proleptic gregorian calendar as being exactly 86400 seconds, we ignore the "cesium" standard for the SI second and treat it effectively as a unit of planetary angular rotation instead. The upside is that it's pretty simple to deal with for programs. The downside is that some seconds are longer than others. 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 minor one is that we have to do a table lookup and addition to get the local date/time corresponding to a particular numbered second in the past or vice versa. 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. This is because fundamentally it's not well predictable - we can't know in advance which years the astronomical union will declare as containing an additional leap second. The only "reasonable" way to deal with it seems to be assuming that future years will be exactly 86400 seconds long but it will not, in fact, turn out to be the case. So you have to convert the planetary-rotation second in the future into a formatted date and time, and then handle conversions back to absolute seconds on the fly (much) later when leap-second data for the intervening years becomes available. So if you're going to use the cesium second, you wind up needing either formatted-dates or the notion of the planetary-rotation second anyway if you want to specify a particular time on a particular date in the future as opposed to a particular number of seconds into the future. Which "second" is preferable depends on the application. Bear _______________________________________________ r6rs-discuss mailing list r6rs-discuss@x http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss