Hello James, thank you for your brief answer. 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... I'm really confused about that fact!
Thank you for helping me with my problem. many regards, Felix Joussein James Youngman schrieb: > On Feb 1, 2008 8:24 AM, Jim Meyering <[EMAIL PROTECTED]> wrote: > > >>> Basicaly the goal ist, to set back the time at a certain moment for 1 >>> Second. It's all about the leap-second which might be set every last >>> second of the 31th of dec. or 30th of june... >>> Doing this with the new date command the time is set back to 2 seconds >>> rather then one... with the old date command using the minute's 60st >>> second a step-back for one second is possible. >>> >>> Do you have any idea how this may happen? >>> > > Leap seconds occur in UTC. They are often handled by the kernel (if > at all) and a common way to do this is to run an NTP client. See > also http://www.cis.udel.edu/~mills/leap.html > > It is normally not necessary to introduce a manual adjustment with > "date" in order to maintain synchronisation. > > James. > > > -- mit freundlichen Grüßen Felix Joussein Integrated Network Design Firma Felix Joussein [EMAIL PROTECTED] _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
