On 14 April 2013 12:50, Levente Uzonyi <le...@elte.hu> wrote: > On Sat, 13 Apr 2013, Igor Stasenko wrote: > >> On 13 April 2013 21:36, Levente Uzonyi <le...@elte.hu> wrote: >>> >>> On Sat, 13 Apr 2013, Igor Stasenko wrote: >>> >>>> >>>> Both #timeToRun and secondsWhenClockTicks (via Delay) using same >>>> primitive >>>> - #millisecondClockValue. >>>> Sure thing, precision of this primitive should be it is 1 millisecond >>>> or smaller.. >>>> But it has nothing to do with precision of primSecondsClock and you >>>> cannot increase precision of >>>> it using #millisecondClockValue. >>> >>> >>> >>> The only thing I wanted to point out is that the value of >>> #primSecondsClock >>> changes when the actual second changes (the difference is less than 1ms). >>> So >>> while its resolution is just 1 second, it's accuracy is better than 1ms. >>> Here's another example using the microsecond clock: >>> >>> >>> (1 to: 10) collect: [ :e | >>> | start | >>> Time secondsWhenClockTicks. >>> start := Time primUTCMicrosecondClock. >>> Time secondsWhenClockTicks. >>> Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 >>> 999961 999926 1000029 999988 999991 999985 998089 1000034)" >>> >> >> My gut feeling that here you are rather measuring accuracy of 1ms >> Delay operation (in secondsWhenClockTicks method). > > > No. I just wanted to show that this method works in practice (yeah, it's > there for years and actually noone had any problems with it). And even > though there's a slight chance for it to drift away by a few milliseconds, > your statement - using a random number for the millisecond part is not worse > than using this method - is not true. >
Maybe you are right. But i do not see a compelling reason having DateAndTime soo precise. It makes not sense. And TimeStamp's resetting nanosecs field (in very peculiar way) by rounding it to 1sec heavily backing up my argument. If you need precision/accuracy higher than 1 sec, you should use milli/micro second clock counter. The mess in DateAndTime is imo a big piece of overengineering. > Levente > -- Best regards, Igor Stasenko.
