4 ms·
"How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table?" I am not an exp
by timr 14y ago
"How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table?"
I am not an expert, but as far as I know the most automated solutions are doing it via NTP, which just resets the second, then relies on clock drift to bring everything back into synch. Otherwise, I think your only option is to keep the timezone packages up-to-date (which is a non-trivial task for large deployments). A quick search found this:
http://www.novell.com/support/kb/doc.php?id=7001865 http://www.novell.com/support/kb/doc.php?id=7001865
"But the 'solution' we're using now is to make system time less accurate, not more accurate."
Yeah, I'm not disputing this. I'm just saying that preserving the assumption that "day == 86400 seconds" probably breaks less code than the alternative. NTP messes with the notion of seconds-since-epoch anyway, so we know that single-second variations in unix time aren't automatically deadly to most unix software.
- obtu 14y agoNTP sends a special message to the kernel (using adjtimex), that boils down to: today you will insert a leap second. This isn't the same as clock drift, which gets smoothed out, it means a minute with a 60th second (in UTC) or with the 59th second happening twice (in POSIX). NTP servers need a leap second table ( http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14 http://support.ntp.org/bin/view/Support/ConfiguringNTP#Secti.... ), but most other systems only need to know the current delta between POSIX and TAI, and manage without a leap table.