On 10 May 2007, at 15:29, Giacomo A. Catenazzi wrote:
I think the specs ignore the issue, so it is only accurate within
a couple of ten seconds. I figure typical system just ignore the
leap seconds from the epoch, and adjusts the internal clock on the
first lookup after the time server has changed. It is these jumps
in the internal clock that may pose a problem: it is hard to tell
which computer that have adjusted and which have not.
What do you mean with "internal clock"? If you means "the hardware
clock", ignore it. Systems usually save and restore times in hw
clocks only on reboots, so they use the same convention to save
and restore times, so it is not a problem (but eventually with a
networked file system, with the machine down between leap second and
update of the leap-second file).
If you just have one computer or a set of computers using the same
clock, it really does not make any difference what time one is using,
if it only increments.
The things I discussed are only of importance in a distributed
setting, with a set of independent clocks, that are expected to
measure physical time (like with coordination with physical events).
There, one can note that physical events are (according to GR) only
causal if they are within each others light cones. Light travels
about 0.3 m in a nano-second. So time stamps differing with a nano-
second can only be separated as physical events at shorter cable
distance.
It really depend on interface of the hardware clock: if clocks support
seconds (since epoch) or if you should use a MM/DD/(YY)YY HH:mm:ss
interface, and I doubt POSIX could change such hardware capabilities/
It is the adjustment of the epoch so that it relates to the
measurement of physical time. The clock of a typical computer isn't
set to the seconds since 1 January, 1970, but to that date adjusted
with the number of leap seconds that have occurred since that date,
because that is what it gets from the time server. Computer are
clearly restricted use the hardware they have.
Hans Aberg
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
