BRIEF DESCRIPTION
The (new) BICEPS Corrigendum Note 3 in §B.182 is inconsistent with the use of "pm:ClockState/@lastset" in SDPi's "1:C.2.5.6.1 Safety, Effectiveness & Security Considerations and Requirements" and "3:8.3.2.10.10 Timestamp versioning"
FURTHER CONSIDERATIONS
The note in §B.182 of the corrigendum is inconsistent with the use of @lastset in SDPi, where it stores the most recent time that is unambiguously in the current epoch (R1522). This is important to resolving time stamps, but it could be pushed into the extension. The downside is that every clock state would need the extension to be present (currently it would only be present in the unlikely event of an abrupt time step). This ticket has been filed to address this issue, assuming the requirement in SDPi can't trump the note in the corrigendum.
NOTE: This is a finding spun out from #485
BRIEF DESCRIPTION
The (new) BICEPS Corrigendum Note 3 in §B.182 is inconsistent with the use of "pm:ClockState/@lastset" in SDPi's "1:C.2.5.6.1 Safety, Effectiveness & Security Considerations and Requirements" and "3:8.3.2.10.10 Timestamp versioning"
FURTHER CONSIDERATIONS
The note in §B.182 of the corrigendum is inconsistent with the use of @lastset in SDPi, where it stores the most recent time that is unambiguously in the current epoch (R1522). This is important to resolving time stamps, but it could be pushed into the extension. The downside is that every clock state would need the extension to be present (currently it would only be present in the unlikely event of an abrupt time step). This ticket has been filed to address this issue, assuming the requirement in SDPi can't trump the note in the corrigendum.
NOTE: This is a finding spun out from #485