Warner Losh wrote: >By catering to the sucky implementation, it precludes the precision one :(
Doesn't preclude it. The only real omission around the Clock class is that the API provides no way for a Clock to advertise its accuracy, precision, stability, or related features; accuracy is only claimed out-of-band. So you could say that the API precludes *recognition of* the precision implementation. I suspect that this will be the first thing to be rectified in the next round of standardisation, following real-world experience with JSR-310. (You need a method on Clock that yields the current Instant plus an inaccuracy bound applying to that reading, not (only) a separate method that yields a non-specific accuracy parameter.) Likewise, precision computation with points represented on the Java time scale isn't precluded, it's just out of scope for the standardised library. -zefram _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
