ce messages to signal that a Leap61 event is coming. This is done ahead of time SO that if the slave is disconnected from the GM during the switchover time, then the slave clocks are still aware that the leap event is happening. In normal operations, PTP uses the PTP timescale, which means that the timestamps reflect atomic clock time, Temps Atomique International (TAI). There are no leap events in the TAI timescale be- cause it is monotonic. So, it is very important to understand that the leap second has no effect on the PTP timestamps. It affects only the contents of the Announce message, which is then reflected in the PTP datasets. The only scenario in which the UTC offset is needed is if a slave clock needs to convert the PTP timestamps into UTC (for any purpose requiring a human-readable timestamp or even as a source for an NTP server). As an artificial example, the following shows what would happen on a PTP slave clock when the time for the leap second arrives. First, the slave receives the Announce message signaling that the leap second is coming in the next 12 hours. Then, 12 hours later, the Announce message is updated to clear the leap second flag, but increments the UTC offset from 37 to 38. Dec 31 12:00:20.823: ptpd: Old leap61 Flag is 0 New leap61 Flag is Jan 01 00:00:00.000: ptpd: Old leap61 Flag is 1 New leap61 Flag is ( Jan 01 00:00:00.000: ptpd: OldUtcOffset is 37, New UtcOffset is 38 See Annex B of IEEE 1588-2008 for detailed information on the usage of timescales and epochs in Should the Clocks Run UTC or TAI? As you read in the previous section, under normal conditions, PTP uses the PTP timescale, which means that the epoch is based on the PTP epoch (1 January 1970 00:00:00 TAI), and the timescale is TAI. See the section "Timestamps and Timescales" in Chapter 7 for more details. Some engineers ask why they must deal with PTP timestamps based on TAI and all this leap second hassle, when the fact is that they want to see UTC. Some suggest they want to run their PTP install- ation on UTC, rather 