On 12/15/10 11:09, Vitaly Magerya wrote: > On 2010-12-15 12:22, Alaric Snell-Pym wrote: >>> You can't use TAI to represent dates in the future, >>> as it would require leap seconds tables that are only published six >>> months before the leap seconds occur. >> >> But we're not trying to represent dates; we're trying to represent the >> pssage of time. > > Any monotonic clock with unspecified origin is sufficient to represent > passage of time. Agreed > What Alex suggested was to use TAI clock specifically > to represent both passage of time and UTC (civil time, wall clock time, > "date", call it as you wish). Was it? I thought he was just arguing that TAI (which goes up linearly) was better than POSIX seconds (which go up nonlinearly due to leap seconds), rather than an argument about whether we should present absolute or relative time. Personally, on the latter point, I'd be inclined to standardise relative time as the most basic standard, as tiny systems can at least start a reasonably accurate second counter at startup, even if they lack absolute clocks. A separate procedure that returns the offset between relative time and some epoch, or #f if this is not known, would be the next level, offering an absolute time reference... >> We'd use a date object (which refers to a particular >> calendar) to represent dates. > > That seems like the only reasonable choice: have a complex "date" object > for UTC, and a simple monotonically increasing number for physical time > (and drop the assumption that you can freely convert between the two). That'd be fine by me! A procedure that returns the number of seconds between two arbitrary dates (along with a certainty, so that dates extending beyond the current leap-second table, or back beyond UTC began, can give approximate answers) would round it out nicely. >> Then perhaps Scheme distributions will come with a leap-second file, and >> encourage its periodic updating. That shouldn't be too burdensome... > > "Periodic" means every 6 month, and there are lots of places where this > is burdensome (which is why we have things like IE6 and Debian Stable). > Yeah, I know, but such environments just can't have accurate UTC <-> actual time conversions, full stop. So they'll have to have approximations (and, ideally, be informed of this fact using a certainty flag, etc). ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
