During interoperability testing, some boundary clocks did not propagate the leap61 flag correctly, probably because they were disconnected from their master and reconnected in the last minute before the leap second. Another explanation was that the Announce message propagated after the leap second occurred with an obsolete value of currentUtcOffset, resetting effectively the leap second.
This uncovered the issue that there exists no prescription on how the leap second is propagated and the UTC time value computed. IEEE 1588 does not prescribe how short in advance the leap second is indicated, it assumes it is 12 hours prior to midnight UTC or "when the grandmaster determines that the value is TRUE" (?) and gives no guidance for UTC.
Its specification "The update of timePropertiesDS.currentUtcOffset, timePropertiesDS.leap59, and timePropertiesDS.leap61 shall occur prior to one announceInterval past midnight (UTC) of the day in which the leap second occurred." effectively can cause a problem if the Announce message is sent during a leap second before "midnight".
Therefore, a recommendation is needed so that implementers have the same understanding. It is formulated as a “should” since testing this behaviour would require an inside view of the clocks.
Proposal
NOTE 1: The PTP binary second counter is usually a 32-bit counter since the epoch 1970-01-01 00:00:00 TAI. The UTC time register is a 32-bit register that indicates the number of seconds since the epoch 1970-01-01 00:00:00 UTC, its value lags currently (2017) 37 seconds behind the PTP time counter. The scaled nanosecond, millisecond or binary fraction of second counter is the same for UTC and TAI. Other epochs such as SNTP uses are treated similarly.
NOTE 2: Both for UTC and TAI, the binary value of second 00:00:00 at the start of a day modulo 86400 is 0; the binary value of second 23:59:58 at the end of a day modulo 86400 is 85398; the binary value of second 23:59:59 at the end of a day modulo 86400 is 85399.
NOTE 3: Although the leap second can only occur at the end of a month, the method specified here applies to any day with no restriction of the month.
A slave clock should derive the UTC binary second time by subtracting the value of its UtcOffset register from the PTP binary second counter.
When a slave clock receives an Announce message with a flag currentUtcOffsetValid =TRUE, it should set the value of its UtcOffset register to currentUtcOffset, with the following exceptions.
a) If the Announce message contains a flag leap61=TRUE, the slave clock should prepare an increment of the UtcOffset register that will enter in effect after the end of the UTC second 23:59:59 of the day. It should ignore the value of currentUtcOffset, leap61 and leap 59 after the end of the UTC second 23:59:58 of the day and for the next 10 s and raise an exception if after 10 s the value of its UtcOffset register differs from the received currentUtcOffset or if the leap59 or leap61 flag are still set.
The slave should keep a flag “leapSecondOngoing” that is set during the leap second 23:59:60.
NOTE 4: Thereafter, the UTC binary register has the same value for second 23:59:59 and 23:59:60. The samples can be distinguished by “leapSecondOccurring”.
b) If the Announce message contains a flag leap59=TRUE, the slave clock shall prepare a decrement to the UTC offset register that will enter into effect after the end of the UTC second 23:59:58 of the day. It should ignore the value of currentUtcOffset, leap59 and leap61 after the end of the UTC second 23:59:58 of the day and for the next 10 s and raise an exception if after 10 s the value of its UtcOffset register differs from the received currentUtcOffset or if the leap59 or leap61 flags are still set.
NOTE 5: Thereafter, the UTC binary counter does not show a value for the second 23:59:59 of that day.
Discussion
Created
Status
This issue is solved, but not in the sense of the proposal.
IEEE 1588-2018 Draft says: <currentUtcOffset> = TAI - UTC
BIMP Bulletin C 52 says: currentUtcOffset is incremented after the end of the leap second.
IEC 61850-7-2 2.1 adopted this view, which is in line with 8-1 Ed.2.
Only a clarification is needed that the binary value of the leap second in secondsField or secondSinceEpoch is divisible by 86'400 during a leap second and that the flag leap61 is cleared exactly at midnight, midnight being defined as the beginning of the first second of the next day after the leap took place. This allows to generate the LeapSecondKnown flag in IEC 61850-7-2 Timestamp.
19 Oct 18
In Force (green)
The current proposal does not say anything different from IEEE 1588-2008.
IEEE 1588-2008 says that currentUtcOffset and leap61 change value at midgicht, clarification is that midnight is the first second of the next day after the leap second insertion or removal.
This is not a question of what the slave sees, it is the grandmaster that takes the decision.
20 Apr 18
Ballot Period
This topic is currently under discussion in P1588. The publication of IEEE 1588:201x will reveal, whether e.g. its section 9.4 as pointed out by Amin is sufficiently clear. Until then, this Tissue is put "on hold".
15 Feb 18
Future Improvement
There is currently intensive debate in P1588 around this question.
In any case, the standard must define the precise moment of the transition, and indicate that the leap is not observed for the next 12 hours.
30 Jan 18
Ballot Period
Section “9.4 Grandmaster PTP Instance timePropertiesDS updates” of IEEE1588 draft revision (P1588/D1.2, Ballot-2 2017 V2.01) is sufficiently clear. We should gain some implementation experience from IEEE1588 draft revision before extending profile.
30 Jan 18
Ballot Period
Please consider that this proposal is independent from a decision to allow or not the use of TAI in IEC 61850. The scheme proposed is in line with IEC 61850-7-2 Ed.2.1 draft.