PQC152 — Time sync capability and implementation must agree¶
capabilities.time_syncandCapability.ITimeSynchronizeddisagree: one is present without the other.
Time synchronization takes two halves. The capability flag in adapter-registration.yaml is what makes the framework schedule a sync at all. The interface is what performs it when the scheduler calls. Either one alone does nothing, quietly.
Why the build refuses this¶
The failure is silent in both directions. A declared capability with no implementation schedules work nothing carries out. An implementation nobody declared is never called. Neither logs an error, neither fails a test, and both look correct while reading either file on its own.
What it costs is timestamps. A panel whose clock is never set drifts, and every event it stamps drifts with it. Nobody notices until an audit log has to be read back against something else — usually during an investigation, which is the worst moment to discover the clock was wrong for months.
How to fix it¶
If the device has a settable clock, implement the interface on the Thing that owns it and keep the flag true:
public Task SynchronizeTime(TimeProvider timeProvider) =>
Protocol.SetClock(timeProvider.GetLocalNow()); // pass the offset through - see PQC257
If it does not, set time_sync: false and drop the interface. An adapter that cannot set the clock should say so, not carry a scheduled no-op.
Note that the provider handed to SynchronizeTime is zone-aware; converting its result with .LocalDateTime is a separate defect, reported as PQC257.
What is not reported¶
Which Thing implements the interface. The rule cares that some type does, not which.
Whether the synchronization is correct. That it runs is all the build can see.
If you disagree with a report¶
Do not suppress it. A wrong report is a bug in the check — report it with the code that triggered it.