> From: John Cowan <[email protected]> > > > What does Posix have to do with a language that may be implemented on > > any OS? Use UTC. > > With what epoch?
I don't care at all, it's one addition to convert the epoch. Use the Posix epoch if you like it, I did not specify because I don't think it matters. > If you are to represent time as a number, > there has to be a zero time, or epoch. Obviously. Choose any you like. > > In particular, Posix torques up leap seconds. > > Yes, it does. But almost all computers do too. And will continue to do so if it keeps getting written into standards. > In any case, most computer clocks aren't accurate to > 1 part in 10^8, which is the discrepancy between > Posix time and UTC time since the beginning of UTC. How many milliseconds is that? > > Trying to put both time-and-date *and* precise > > sub-second intervals into one number is a loser. > > Why? Because time-of-day does not increase at a uniform rate. > 2^53 is a lot of range, and the further away from the > present, the less precision we need or even can use, > given the fundamental uncertainties about things like > day length. It doesn't even make sense to ask about > UTC time much before 1970. I am not worried about precision, I am worried about correct arithmetic. > > In particular, does the current "instant" increment > > uniformly, or does it encode the current date? It > > can not do both, and it is unclear which you > > intend. > > The latter, as Posix clock() does. Write that more clearly and point out the implications. Or leave it up to the implementation, as I advocate. > > It may or may not be incremented when a leap second > > passes. > > The same as what I'm proposing, except that "may or > may not" is just "may not" in my proposal. You are *forbidding* an implementation to increment the clock before a leap second? > That way, at least every second except a leap second > and the preceding second have fully specified instant > values. In your proposal, there's no knowing what > they mean, as some leap seconds but not others may be > accounted for if the leap-second file (or other > source) is out of date. So what does your proposal do when the file is out of date? I think the uncertainty is inherent in the situation. But not important for purposes of printing the date on the contract. > This is a good API, but functionally disjoint from > what I'm dealing with now. I agree. I have no problem with your method of printing the Mayan or French revolutionary calendar. They don't need millisecond accuracy. You can fix the whole problem, as far as I am concerned. simply by making your instant into an count of seconds with no fractional part. Then the sub-second timer can be added as separate API. Otherwise it's false advertising. -- Keith _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
