GAP:
The TimeStamp data type is used to time stamp events, Synchrophasors, and SV in 61850. TimeStamp is based on UTC and thus, when a leap second occurs, there are 2 identical time stamps. In as much as an event in one IED may have happened prior to Leap Second and an event in a second IED may have occurred during the actual Leap Second, the result is that in post event analysis, the delta t between events cannot be computed. Even though there is discussion to create a new DO for Leap Second, this does NOT address the issue of time stamping in a Sequence of Events, SV, and Synchrophasor records.
Proposal
Needed: a mechanism to identify an active leap second in TimeStamp; secondary need: the ability to identify a "negative" leap second pending in TimeStamp.
Proposal: In 8-1, the Time Quality definition in Table 32 (page 54) identifies the values of 25 through 30 as "invalid". It is proposed that the value of 30 in the Time Quality value be identified as Leap Second Active; As a second proposal - to identify that the next second is going to be missing (a negative Leap Second), the TimeStamp for the next-to-missing second shall have a Time Quality value of 29. This implementation would also be used with Synchrophasors and SV as reported from the PMU or MU accordingly.
Discussion
Created
Status
several discussions on going regarding to the management of leap second need to converge and deliver the solution for handling leap second as well as a migration scenario for Ed2.1 client with Ed1/Ed2 Servers.
21 Sep 15
Future Improvement
if we use the time accurcy for indicating the leap second, what is then the valid time accuracy during the leap second??
i.e. the valid number of bit in the fraction of second field.
as for TAI and leap second, devices need to known the leap seconds in oder to convert a TAI time to a local time. Interoperability when using TAI can only occur when a table of the TAI representation of the past leap seconds is made available for every IEDs on the network.
17 Aug 15
Discussion (red)
We need to have this capability so that when a leap second is applied, the 2 seconds can be differentiated. Again, this is based upon requirements for Synchrophasors (e.g. C37.118).
04 Aug 15
Discussion (red)
The idea sounds good, but has a loophole: if the comparison interval between samples spans more than one second, the algorithm will not be able to recognize that a leap second was inserted if it does not find at least one value with the "leap second" flag set.
The only clean solution to that problem is to use the PTP time scale based on TAI and not the UTC time scale. In fact, UTC should be considered a human-readable time indication of the same nature as local time and deaylight saving time, but not used for technical operations.
This question could become obsolete in November 2015, as ITU-R will debate the abolition of the leap second, under pressure of the financial markets.
Therefore, I propose to reopen this isssue in 2016.