Leap Seconds
As of version 5.1 of Domain Time, leap seconds are scheduled to be applied on the last day of the month, immediately after the 60th second of the 59th minute of the 23rd hour UTC. By convention, leap seconds are applied to all clocks in the world at the same moment. Previous versions of Domain Time did not account for leap seconds, but merely applied the changed time as a normal correction during the first time check after the leap second occurred. The remainder of this document discusses the behavior of Domain Time II version 5.x and later.

Domain Time learns about leap seconds from time sources announcing leap seconds (generally a GPS-connected source using either NTP or PTPv2). If a Domain Time Server knows of an upcoming leap second, it will inform clients being served by NTP and, as of version 5.2.b.20110601, the DT2 protocol. If a Domain Time Server is configured to be free-running (that is, serving the time without using any time sources), it will not know about pending or past leap seconds.

NOTE: If Domain Time is configured to obtain its time from multiple sources, all sources must agree on the upcoming leap second. Domain Time will reject leap seconds if its sources do not agree with each other.

Leap second insertions (a minute with 61 seconds) are supposed to generate a time sequence like this:

Due to the nature how leap seconds are calculated, a leap second deletion (a minute with only 59 seconds) has never occurred. However, NTP and PTPv2 are both capable of signaling a pending deletion if necessary, and Domain Time handles it much the same way as it handles an insertion. Instead of slowing the computer down temporarily, it speeds the computer up. The last minute of the day will end up with only 59 seconds. Processes will see the time slewing forward for approximately half of a second, after which wall clocks and computer time will again match.

Logs and Confirmation
Administrators can check NTP sources for pending leap seconds using the command-line NTPCheck utility provided with Domain Time:

where "host" is either an IP address or a DNS name. NTP servers may begin showing a pending leap second as early as a month before it is due, or as late as the day of. Since leap seconds are defined as occurring on the last day of the month, and the flag does not include date information, the flag cannot be set more than a month ahead. Some servers will only set the flag on the day the insertion is due. Query your hardware vendor for details on your particular model's behavior. The software implementation of NTP typically uses a file referenced in ntpd.conf to specify the date of upcoming leap seconds. Hardware clocks usually get the information from GPS or radio.

PTPv2 servers normally get their leap second information from GPS and require no configuration.

Domain Time notes the leap flag when it queries its time sources. If all sources agree that a leap second (either insertion or deletion) is due, Domain Time calculates the offset between the current time and the last second of the month, and schedules an event for that exact time in UTC. Corrections to the clock between the scheduling and the event are automatically accounted for by the operating system, so the event will fire at the desired moment. Domain Time will note the scheduled event in the text log, saying which server informed Domain Time of the upcoming leap, the scheduled time in UTC, and the scheduled time in local time.

If subsequent time checks reveal a disagreement with the previously-scheduled event, or all of Domain Time's sources do not agree, the event is cancelled. Domain Time notes this cancellation in its log.

When the event occurs, Domain Time adjusts the clock as needed, and notes the reason for the adjustment in its log. It then records the time the adjustment was made, and ignores the flag (if still set by any sources) until a minimum of 45 days has passed since the leap second was applied. This prevents duplicated leap seconds caused by servers that fail to clear the flag promptly after the event has passed.

For PTPv2 (IEEE 1588-2008/2019), the TAI-UTC offset is automatically adjusted to compensate for the leap second. PTPv2 grandmasters use a mechanism similar to the NTP leap second pending flags. They will also adjust their own TAI-UTC offsets, so even without leap second scheduling enabled, a machine using PTPv2 as its source will leap correctly.

Domain Time does not preserve pending leap second information between restarts of the Domain Time service. If a leap second event begins being announced while Domain Time is not running, Domain Time will discover the information when it checks its sources after startup. If a leap second event occurs while Domain Time is not running, the event has already passed and should not be scheduled. Domain Time will account for the extra second at the startup correction.

You may disable Domain Time's advanced scheduling of leap seconds by unchecking the box on the Advanced tab of the Control Panel applet. If this box is unchecked, then Domain Time will account for the leap second the next time it checks its sources after the leap event has occurred. Correction for the extra second will be handled exactly as if the clock were really off by that amount (i.e., slewing or stepping, based on your configuration).

If advanced scheduling is disabled, but Domain Time discovers a pending leap second when it queries its sources, it will note in the log that the leap second is pending but not scheduled.

Leap second log entries are "Information" level. You do not need to change your log to trace or debug to see leap second activity.