Every six months the International Earth Rotation Service (IERS) issues a bulletin announcing if there will be a leap second in the Universal Coordinated Time (UTC) timescale. Historically, only insertions have occurred, about every eighteen months. The changes have been at the end of the last day of June or December; but, in principle, it could happen at the end of any month. While these bulletins are available on the Internet at www.iers.org, advance notice of leap seconds is also available in signals broadcast from national time and frequency stations, in GPS signals and in telephone modem services. Many, but not all, reference clocks recognize these signals and many, but not all, drivers for them can decode the signals and set the leap bits in the timecode accordingly. This means that many, but not all, primary servers can pass on these bits in the NTP packet heard to dependent secondary servers and clients. Secondary servers can pass these bits to their dependents and so on throughout the NTP subnet.
A leap second is inserted following second 59 of the last minute of the day and becomes second 60 of that day. A leap second is deleted by omitting second 59 of the last minute of the day, although this has never happened and is highly unlikely to happen in future. So far as is known, there are no provisions in the Unix libraries to account for this occasion other than to affect the conversion of an NTP datestamp or timestamp to conventional civil time.
When an update is received from a reference clock or downstratum server, the leap bits are inspected for all survivors of the cluster algorithm. If the number of survivors showing a leap bit is greater than half the total number of survivors, a pending leap condition exists until the end of the current month.
When no means are available to determine the leap bits from a reference clock or downstratum server, a leapseconds file can be downloaded from the IETF and installed using the leapfile command. The file includes a list of historic leap seconds and the NTP time of insertion. It is parsed by the ntpd daemon at startup and the latest leap time saved for future reference. Each time the clock is set, the current time is compared with the last leap time. If the current time is later than the last leap time, nothing further is done. If earlier, the leap timer is initialized with the time in seconds until the leap time and counts down from there. When the leap timer is less than one month, a pending leap condition exists until the end of the current month. If the leapseconds file is present, the leap bits for reference clocks and downstratum servers are ignored.
If the precision time kernel support is available and enabled, at the beginning of the day of the leap event, the leap bits are set by the Unix ntp_adjtime() system call to arm the kernel for the leap at the end of the day. The kernel automatically inserts one second exactly at the time of the leap, after which the leap bits are turned off. If the kernel support is not availed or disabled, the leap is implemented as a crude hack by setting the clock back one second using the Unix clock_settime() system call, which effectively repeats the last second. Note however that in any case setting the time backwards by one second does not actually set the system clock backwards, but effectively stalls the clock for one second. These points are expanded in the white paper The NTP Timescale and Leap Seconds. If the leap timer is less than one day, the leap bits are set for dependent servers and clients.
As an additional feature when the NIST leap seconds file is installed, it is possible to determine the number of leap seconds inserted in UTC since UTC began on 1 January 1972. This represents the offset between International Atomic Time (TAI) and UTC. If the precision time kernel modifications are available and enabled, the TAI offset is available to application programs using the antipasti() system call.
You may also wish to read the page on leap smearing.