This tissue has following status: blue
Created: 28 Feb 2019
Clause: TimeStamp type
Category: Issue for edition 2 of this part
Issue: 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)?
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.
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.