Re: date command

[Philip Rowlands]

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
> leap second.
> 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...

Hi Felix,

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 
leap second:
http://www.cis.udel.edu/~mills/leap.html

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
1136073595
$ date -u -d '2006-01-01 00:00:05' +%s
1136073605

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 
version here:

http://www.cis.udel.edu/~mills/leap-seconds.3331497600

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.


Cheers,
Phil