Define the Timestamp Mismatch
The reported tag, downtime, had an expected event time of 2025-03-10 11:22:20, while the client displayed 2024-12-11 17:19:59. The live Ignition tag timestamp and its historical timestamp appeared correct. The fault is occasional and affects only some tags, so the available evidence does not establish a system-wide clock error.
| Observation point | Observed result | Diagnostic meaning |
|---|---|---|
| Live Ignition tag | Timestamp appears correct | The current tag timestamp is not the demonstrated failure point. |
| Ignition history | Historized timestamp appears correct | The stored history does not reproduce the reported mismatch. |
| Client | Occasionally displays an incorrect timestamp | The mismatch is visible downstream, but its exact introduction point is unknown. |
Locate the First Incorrect Value
The key unresolved question is where the timestamp first changes. Determine whether the timestamp remains correct at the Ignition Transmission side, whether it changes at the Engine side, or whether it changes only when the client interprets or displays the data. A correct live tag and historian record do not prove that the timestamp carried through the publishing path is correct.
Capture One Fault Across the Full Path
- Choose an affected tag such as
downtimeand record the event value and timestamp at the live Ignition tag. - Record the corresponding historical entry and confirm whether its timestamp matches the live tag event.
- Capture the same published event at the Transmission side and then at the Engine side, preserving the timestamp representation at each point.
- Record the timestamp shown by the client for that same event. Identify the first observation point where
2025-03-10 11:22:20becomes2024-12-11 17:19:59. - Repeat the capture for an unaffected tag during the same period. Compare the affected and unaffected paths without assuming that all tags use identical publishing or client-processing behavior.
Interpret the Result
If the timestamp is already wrong at the Transmission side, investigate how the published record selects or retains its timestamp. If it is correct there but wrong at the Engine side, isolate processing between those points. If both sides preserve the correct value and only the client is wrong, inspect the client’s timestamp parsing and display path. The evidence does not provide payload captures, configuration, module versions, or client details, so it cannot support a narrower root-cause claim.
FAQ
Why can an MQTT client show the wrong time when the Ignition tag timestamp is correct?
The timestamp may change after the live tag is read. Compare the same event at the Transmission side, Engine side, and client to find the first incorrect representation.
Does correct Ignition tag history rule out a publishing timestamp problem?
No. The reported history timestamp is correct, but the client displayed 2024-12-11 17:19:59 instead of 2025-03-10 11:22:20; the published path must be captured separately.
How do I troubleshoot an intermittent wrong timestamp affecting only a few tags?
Capture one affected tag and one unaffected tag across the live tag, history, Transmission side, Engine side, and client. Use the first point where their timestamp behavior differs to define the fault boundary.