> From: Ray Dillinger <b...@sonic.net> > > FWIW, I like this proposal.
Thanks for the positive feedback. Some things you said made me think I had not made the proposal clear. The milli-second by milli-second accounts of the passage of a leap second were not meant as part of the proposal, but as a reductio ad absurdum of the whole idea of counting milli-seconds on the calendar. > On the naming of names, I think I'd go with a different name > for the procedure time-and-date mentioned above. OK. I am not attached to the names. Let me try again. > c) If you have the information available and you want to go > for canonically correct behavior, the preferred mechanism > would be to have the clock of calendrical seconds just plain > stop (milliseconds and all) for exactly one second while the > leap second passes. One thing I insist upon is that the clock never go backward. I also think it is misleading and dangerous to offer a milli-second timer that is sometimes drastically wrong. (That is, there will always be bugs and compromises in the implementation, but the _standard_ should encourage, not forbid, correct behaviour.) I started to write a polemic, but I learned how to use the versioning system at http://trac.sacrideo.us/wg/wiki and found that some things that I wanted to argue about had already changed. I am basing the following on version 14. 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. There may be historical events for which sub-second timing is relevant, but in these cases the timing is relative to an epoch that depends upon the event, e.g. the start of the Zapruder film[2]. The length of a day is not constant, and the average is not an an integral number of seconds. 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. (Proposal: At http://trac.sacrideo.us/wg/wiki/TimeAdvancedCowan <delete paragraph on instants, replace with following> 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: (make-date favorite-chronology '((utc . 0))) <delete date field called instant, replace with following> utc The universal time count corresponding to this date. This field is required in every date. It is an integer. <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. :end-proposal) At http://trac.sacrideo.us/wg/wiki/TimeCowan 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? Why must the number of jiffies per second be an integer? (Proposal: <add the following> (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). Elapsed time ------- ---- (current-elapsed-time) A real number giving the time in SI seconds since the epoch. (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. The epoch of elapsed time will not change while the program is running, but is otherwise quite arbitrary. There could be extentions that make or find new timers with special hardware or special epochs, in which case the above procedures take an optional argument, which is the timer. :end-proposal) I spent an evening writing a proposal based upon RFC-5905 (Network Time Protocol) with separate counter and fractional part and advance notice of leap seconds, but I deleted it all the next morning. This is needed to keep the clock synchronized, but it is not a good way to present the result. We don't want to tempt the user into adding the civil count to the physical offset to get a nonsense number. It is left as an exercise to extend this proposal so that is provides a convenient interface to a computer traveling at .98c between two black holes. -- Keith Wright [1] I know it says rational, but I can't imagine why. Unless you know something about quantum physics that I don't, it seems that there must be irrational instants. [2] Google it if you don't remember where you were. [3] More precisely, the calendrical/utc second that immediately precedes the leap second is 2 SI seconds long. That is, the sixtieth and final utc-second of the final minute of the day, which is numbered 23:59:59 is followed two seconds later by 00:00:00, so that the final minute is 61 SI seconds long. [4] The posix epoch will do. I would prefer J2000.0, but in any case the Universal Time Count is not a reasonable encoding of time that must be interoperable between systems. Convert to ISO chronology and transfer in ISO-8601 form. I haven't checked this, but I believe in ISO-8601, time is broken into days, hours, minutes, and seconds, and seconds can range from 0 to 60 inclusive. That is, there can be 61 seconds in a minute, so I think it would be wrong to rule out the sixty-first second. It will be needed in at least some chronologies. _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
