System.Time.Clock Design Issues

[Marcin 'Qrczak' Kowalczyk]

Keean Schupke <k.schupke at imperial.ac.uk> writes:

> If the machine is not networked then its time cannot be compared to
> other time sources, so absolute time is meaningless...

It's still meaningful that filesystem timestamps are interpreted by
Haskell programs in the same way as by other programs. Even if the
current time as measured by the system might be disconnected from
the reality and off by a few seconds, it's internally consistent
across programs.

Without network connection we know the intended UTC of timestamps,
i.e. how the second counter should be converted to calendar time for
display, even if this actually happened some time after or before the
given time. We don't know TAI because we don't necessarily have an up
to date leap second table.

If there is a way to support TAI without disrupting the interpretation
of the time on systems which use UTC everywhere, then it's fine by me.

> I am pretty sure the "clock()" function returns a millisecond count,
> which added to the hardware time at switch on

No, it measures CPU time of the current process with an unspecified
point of reference (usually the first clock() call). If the process
is waiting for I/O, its clock doesn't tick.

On systems with 32-bit clock_t it rolls over after 72 minutes. POSIX
says that CLOCKS_PER_SEC should be 1000000, no matter what the actual
clock accuracy is.

clock() is useful for comparing performance of algorithms, even if
there are other processes competing for the CPU. It doesn't completely
eliminate their influence on the measurement though - if many other
processes are running, less data fits in processor cache.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/