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.