[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: date command

From: Philip Rowlands
Subject: Re: date command
Date: 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
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:

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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]