Per default, TimeKeeper handles leap seconds by “slewing”, rather than introducing discontinuities, “jumps” or pauses in time to correct them. It will smoothly adjust any offset introduced by a leap second to ensure monotonically increasing time.
Some time keeping methods and time reference sources do pause the clock and TimeKeeper will deal with them gracefully. This will initially show up as about a 10 second offset of the time which will be smoothly corrected out over the next three to eight minutes.
TimeKeeper does offer a mode to “jump” the clock or perform a “step” when the leap second occurs in order to reduce the amount of time needed to correct out the time offset introduced by the leap second. To enable this feature:
- Navigate to Configuration > TimeKeeper configuration, and click the field next to the Application Setting "Correct a leap second with an immediate clock jump instead of slew".
In this mode, when TimeKeeper detects a 1 second offset within a 15 second window of when a leap second is introduced (either midnight UTC of June 30, or December 31 of a year) it will immediately correct the clock by 1 second. Note that depending on how leap seconds are propagated within your time environment, this may not occur exactly when the leap second occurs.
We recommend testing how a leap second is handled in your specific environment by simulating one if very fast correction of a leap second is important to you. Please contact Spectracom Technical Support for assistance, see Technical Support.
VelaSync's GPS source (and any other GPS time source) provides time via a UTC broken down format. This means that normally an additional second will be sent to TimeKeeper at the 23rd hour, 59th minute and 60th second of the day when the leap second happens.
This will show up on the server as 1 second after the 23rd hour, 59th minute and 59th second of the day. When the new day starts in the next second – 0th hour, 0th minute and 0th second –TimeKeeper will calculate this as the same second as was previously reported by the time source. This will mean TimeKeeper will calculate an error of 1 second at that time.
Over the next few seconds TimeKeeper will work to remove that error through slewing. Normally this takes 5 to 10 seconds to do. It should be noted that an offset will be expected when leap seconds are introduced and will take 5 to 10 seconds to eliminate. During the time that this offset is being reduced TimeKeeper will not slow down the clock by more than 25% of its original value.
Most NTP protocol implementations will handle leap seconds by pausing the clock at some point in the last second of the day. TimeKeeper does not do this. Below is an example of querying a typical non-TimeKeeper NTP server at 0.25 second intervals during a leap second.
Response from some non-TimeKeeper NTP servers:
If a TimeKeeper instance is configured to act as a client to one of these non-TimeKeeper NTP servers, TimeKeeper will slow it’s own clock down slightly so that it can match the remote clock that is paused until the 1 second offset that was introduced by the leap second is corrected. This offset removal should take a few seconds.
TimeKeeper acting as an NTP server will not set the “leap second indicator” flag in responses that it sends. It will track the time of any source that it is configured to use and will send that time out to any requesting NTP clients. It will not pause the clock at any point and any offsets introduced by the leap second will be corrected through slewing without introducing pauses or jumps.
TimeKeeper as a PTP client will see a leap second occur when a PTP Announce message sent by the server shows a change in the UTC offset field. At that point, TimeKeeper will begin to correct the offset introduced by the change in TAI to UTC offset values. This occurs whenever the server sends the new UTC offset in an announce message and that can vary depending on the server. This could be quite some time after the actual leap second.
TimeKeeper acting as a PTP server will not set the “leap second indicator” bit in announce messages to clients. When the leap second occurs according to the source feeding the server, TimeKeeper will slew to match the source and will provide that time to the client without introducing a discontinuity.
A Leap Second is an intercalary one-second adjustment that keeps broadcast standards for time of day close to mean solar time. Leap seconds are required to synchronize time standards with civil calendars, thus keeping UTC time in sync with the earth’s rotation.
If it has been determined by the International Earth Rotation and Reference Systems Service (IERS) that a Leap Second needs to applied, this time correction occurs only at the end of a UTC month, and has only ever been inserted at the end of June 30 or December 31. A Leap Second may be either added or removed, but in the past, the leap seconds have always been added because the earth’s rotation is slowing down.
Historically, Leap seconds have been inserted about every 18 months. However, the Earth's rotation rate is unpredictable in the long term, so it is not possible to predict the need for them more than six months in advance.
Note: Leap seconds only apply to the “UTC” and “Local” timescales. Leap seconds do not affect the “GPS” and “TAI” timescales. However, a leap second event will change the GPS to UTC and TAI to UTC offsets. When a leap second occurs, VelaSync will automatically change these offsets by the proper amount, no matter which timescale is currently being used by the system.