System.Time.Clock Design Issues

[Keean Schupke]

Ashley Yakeley wrote:

>
>I think even people who don't use NTP set their clock to UTC at the time 
>they set it. You can call that TAI with a fixed offset if you want (and 
>an offset we can't discover), but the difference is probably less 
>significant than the clock drift, and in the long term they'll likely 
>eventually set it to UTC again.
>  
>
SO in effect what you are saying is that system time is likely to be
neither TAI nor UTC (as hand setting a clock has a greater than 1 second
error usually, a non-networked machine will never tell the right time (and
even a stopped clock tells the right time twice a day!).

If the machine is not networked then its time cannot be compared to other
time sources, so absolute time is meaningless... as such we are left with
relative time (which is TAI like as it counts seconds from switch on).

If I am timing an interval measured in seconds, I do not want the user
changing the 'calendar time' to affect my accurate timings.

I am pretty sure the "clock()" function returns a millisecond count, which
added to the hardware time at switch on (as the user cannot adjust
time when the machine is switched off - nor can NTP adjust this) gives
TAI (possibly with a different start time).

    Keean.