[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: date command
Re: date command
Fri, 1 Feb 2008 13:41:04 +0000 (GMT)
On Fri, 1 Feb 2008, Felix Joussein wrote:
Basically I am aware of what you said, but as I am operating an NTP
Server which get it's timescale directly from an ATOM clock via the
serial interface, which makes it to a STRATUM 1 server, I have to set
the leap second manually by date command or similar to push forward the
ntp-server timescale for this one second when ever the IERS announces a
The prior system was running on a Red Hat 7.2 where the date command was
able to set the 60th second... unfortunately the version of the
coreutils which is shipped in debian/etch does not.
I'm helping myself now by using the old date command from the Red Hat
distribution which seams to work for my needs but never then less:
Why has a 8 year old version of date a feature, which it's actual
version doesn't have? I cannot imagine, that the code which is necessary
to set the 60th second would blow up the code that much, that the date
project-team decides to blow out that code...
I simply don't think it's possible to use date for the stated goal.
There is no built-in historical knowledge of leap seconds for the
purposes of allowing the occasional ":60" setting - incidentally, the
example given "01/31/2008 14:20:60" was not an official leap second.
These notes explain how the underlying timers are incremented through a
Once a leap second has passed, effectively the system forgets it ever
happened. The following wall-clock timestamps were actually 11 seconds
apart, but date shows only a 10 second gap.
$ date -u -d '2005-12-31 23:59:55' +%s
$ date -u -d '2006-01-01 00:00:05' +%s
The right way (I think) for what you're trying to do is obtain in
advance a copy of the "leapseconds" file supported by ntpd; latest
Stratum-1 clocks need to be told when a leap second is approaching, to
propagate this information through the leap "bits" to their configured
slaves. If this is not done correctly the machines will not march in
step, and the way the ntp protocol works doesn't allow for spot fixes at
or after a discontinuity; the semi-random polling interval would almost
guarantee your population of machines would learn of (and apply) the
change at different times.