At Meinberg we have run a number of leap second tests due to the upcoming leap second event at the end of June.
We found that ptpd's servo loop doesn't apply leap seconds to the OS system time, though the leap second warning is decoded properly from the PTP announce messages in slave mode (I haven't looked if there's a way to make ptpd send a leap second warning in standalone master mode).
Under Linux (and probably *BSD) the leap second warning should be passed to the kernel using the adjtimex() call which is used to discipline the system time, so the kernel can handle the leap second at the correct point in time. Please note the correct point in time is *UTC* midnight, whereas PTP usually deals with TAI time stamps in the network packets.
Immediately after the leap second event the internal leap status flags should be cleared, and the UTC offset has to change by one second. This has to be taken into account in the servo loop which computes the offset between the timestamps from the PTP grandmaster which are usually TAI, and the OS system time which is usually UTC.
Special care needs to be taken if packets are received *during* an inserted leap second. Depending on the system clock implementation in the OS kernel the system time may increase normally during the leap second, and then step back at the end of the leap second, which means duplicate UTC time stamps can occur, or the system time may prevented from being incremented during the leap second insertion (maybe with microsecond or nanosecond increments to avoid duplicate time stamps). In any case, computing offsets during a leap second may yield large differences which could mess up the servo loop. So may be the daemon's servo should simply skip computing offsets during an ongoing leap second.
A quick look at the code shows that under MacOS the adjtime() call is used instead of the adjtimex() call. This call does not support passing leap second warnings to the kernel, and I don't know how this can be done properly under MacOS.