When a positive leap second occurs, the Timestamp attribute cannot accurately describe the specific time at which the event occurred, in the leap second (23:59:60) or in the normal seconds (23:59:59)?
For example:
In the case of device synchronization, event E1 occurs in the normal second just before the positive leap second (23:59:59), while event E2 occurs in the positive leap second (23:59:60). However, E1/E2 has the same TimeStamp: the positive leap second and the normal second use the same UTC seconds(23:59:59); and have the same TimeQuality (LeapSecondsKnown=True, ClockNotSynchronized=False).
In the above example, the Client/Subscriber may mistakenly believe that two events occured in the same second from the E1 and E2 TimeStamp information.
Proposal
For the The TimeStamp attribution, a flag should be added to indicate that the current second is a positive leap second.
OR
Reinterpreting the attributes of the TimeStamp: when the value of the attribute ClockNotSynchronized is FALSE, the SecondSinceEpoch shall always take into account the leap seconds.
When the ClockNotSynchronized is FALSE, the attribute LeapSecondsKnown shall indicate that the current second of the attribute SecondSinceEpoch is a normal second or a positive leap second. When the value of the attribute LeapSecondsKnown is TRUE, means the SecondSinceEpoch is a positive leap second that should be treated as the 61th s. If it is FALSE, means the SecondSinceEpoch is a normal second.
When ClockNotSynchronized is TRUE, the attribute LeapSecondsKnown shall indicate that the value for SecondSinceEpoch contains all leap seconds occurred or not. If it is FALSE, the value does not take into account the leap seconds that occurred before the initialization of the time source of the device. If it is TURE, the value does take into account all the leap seconds.
Discussion
Created
Status
There exists no such concept as "the value of SecondSinceEpoch contains all leap seconds occured". During a positive leap second, the SecondSinceEpoch counter is paused for one second. The count of seconds is always since 1970-01-01 00:00 UTC (epoch), but this origin is moving at each leap second(currently in 2019,1970-01-01 00:00:00 UTC is 1970-01-01 00:00:37 TAI.
Only a TAI time stamp contains all leap seconds that occured since 1970-01-01 00:00 TAI, but expressing TAI has been excluded in 2.1.
01 Mar 19
Not Applicable
I agree, this has been taken care of in Ammendment1.
28 Feb 19
Not Applicable
This issue has already been taken care for in the IEC 61850-7-2 Ed.2 Amendment1, which is estimated to be circulated as FDIS in March 2019.
Therein, an indication for the positive leap second in a timestamp is defined as specific combination of the TimeQuality attributes.