|
|
|
|
|
by jillesvangurp
1400 days ago
|
|
Your computer periodically syncs with other computers to compensate for the time drift. Posix is just an API and a set of conventions. What your computer syncs with (typically via NTP), is a bunch of very precise clocks. Without that, you'd have a lot of time drift. The reason POSIX ignores leap seconds is because a leap second is well below the margin of error that most computer clocks have. They simply are not precise enough. Without syncing they'd be drifting apart many seconds within days/weeks probably. That's also why the leap second correction is not a big deal because it just happens when computers sync. A few seconds correction is just a routine correction. Happens all the time. |
|
That may be how things work for someone's word processor appliance, but on Linux/etc. NTPD or chrony continually estimate your local clocks drift and compensate for it and change their polling rate as a function of uncertainty (e.g. from temperature effects). They save the estimate drift rate in a persistent file on disk (chrony can optionally compensate for temperature effects; see tempcomp in the manpage).
On some random supermicro server here the crhony drift file says that the clock is slow by -33.208515 parts per million (not atypical for a non-temp-compensated oscillator), with an uncertainty of 0.031571 in that measurement.
As a result other than leap seconds there is no discontinuity in your local time, no few seconds correction that you suggest. Just a continuous clock that is steered smoothly to agree with UTC.
This is really important when you're dealing with subsecond events that must be synchronized among distributed systems.
Hosts on my network here that have no special handling of their time keeping will have time that agrees with each other within +/- 100 microseconds (and with UTC, for that matter, thanks to the local gps disciplined clock). Without a local GPS clock you'll get extra uncertainty from network path asymmetry, but that uncertainty is limited to the round trip time... which is a lot less than 1s if your network is at all usable interactively. :)
A 1 second jump would be gargantuan.
For many applications +/- 1 second is fine. But for others it isn't fine. Modern computers with network time available should have no problem being accurate much much better than 1 second.