r6rs...@free-comp-shop.com scripsit: > One thing I insist upon is that the clock never go backward.
No matter how mis-set it is? Set your clock wrong by a day or so, and NTP will not fix it for you. > The main problem I still have is that the calendrical time is a real > number[1], while the sub-second, physical time is an integer. I think > this is exactly backward. I apologize for my previous proposal, which > had integer physical time, it only distracted from the important thing. > In order to avoid anomalous behaviour, the calendar time must be in > integer seconds. On reflection I agree, and the current version (version 17) of TimeCowan now makes (current-posix-second) an integer. I have updated TimeAdvancedCowan to version 15 to reflect this change. > Therefore it is absurd to attempt to associate each instant with a > single number which can be used both for sub-second timing and to > determine civil time and date. This has nothing to do with numerical > range or precision; it is a physical truth. That's why TimeCowan has two different primitive current-time calls. > The universal time count is an integer count of seconds since the epoch > excluding leap seconds[3]. The epoch is implementation dependant[4], > but can be determined by calling: I see no reason to make the epoch implementation-dependent. Pick one epoch and stick to it, and general agreement is that the epoch for Posix time should be the Posix epoch. > utc > The universal time count corresponding to this date. > This field is required in every date. It is an integer. It would be very confusing for UTC to refer to anything but Coordinated Universal Time. > <add the following date fields> > > posix-second > > Essentially the same as utc, but the epoch is fixed > at 1970-01-01 T 00:00:00 Z, and it need not be an > integer. Any fractional part is inherently > inaccurate, though the magnitude of the errors > SHOULD be at most one second. This field exists in > dates in the 'posix chronology. If it's inaccurate, let's not have it. Subsecond time reference can safely be left to the physical time system. > It says that (current-posix-second) returns two values, but doesn't > say exactly how. Does it mean |values| in the sense of R6RS 11.15? > Or does it mean a cons pair? Yes, two values in the sense of R5RS and R6RS. > Why must the number of jiffies per second be an integer? On the assumption that there is at least one jiffy per second, there is no reason for it not to be an integer. If your clock ticks at 37.5 Hz, then set jiffies-per-second to 75 and increment current-jiffy by 2 at each clock tick. > (current-utc) > > Returns an integer, the current universal time count. > > (current-utc-with-leap) > > Returns a pair with |car| the universal time count > and |cdr| a boolean which is #t iff we are in a > leap second. If this is not available, return just > the time count (an integer, not a pair). This is equivalent to what I've got, except that I allow for more ignorance than you do. > Elapsed time > ------- ---- > > (current-elapsed-time) > > A real number giving the time in SI seconds since > the epoch. Equivalent to (/ (current-jiffy) (jiffies-per-second)). > (epoch-of-elapsed-time) > > The utc second during which the current elapsed > time was 0.000. The implementation SHOULD make > the epoch at the beginning of a utc minute. That > is, it should be divisible by 60. This is just > to make sure the epoch is the start of a second > and can not itself be a leap second. I don't want to assume that implementations can supply this. -- John Cowan co...@ccil.org http://ccil.org/~cowan In computer science, we stand on each other's feet. --Brian K. Reid _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
