Summary

  • RFC 5424's optional timeQuality parameters describe the originator's own view of timezone knowledge, synchronization and expected offset; they do not independently test the clock.
  • syncAccuracy is a declared maximum error between synchronization intervals, so its value depends on source reliability and operator configuration that a receiver cannot infer from the field alone.

The confidence label travels with the event

A security analyst comparing two syslog records may see timestamps separated by milliseconds and treat their order as meaningful. But the record's visible time is not the whole story. Was the sender's timezone configured? Was its clock synchronized to a reliable source? What maximum offset did the sender expect between sync intervals? RFC 5424's timeQuality element was designed to let the originator attach a short account of those conditions to the message.

That design is useful precisely because clocks are operational dependencies. A collector can receive well-formed messages from a system whose clock has drifted, whose timezone setting is unknown, or whose synchronization service has stopped. A timestamp's syntax can be valid while confidence in its interpretation remains limited.

Section 6.2.3 defines the message timestamp using a constrained form of RFC 3339. It recommends fractional seconds when the originator's clock accuracy and performance permit them. Section 7.1 then makes room for a separate structured-data element, timeQuality, which may describe the originator's notion of system time. The word “notion” matters: this is an account from the source, carried alongside the event, rather than a verification performed by the collector.

Section 7.1 says the originator should write timeQuality when it is not properly synchronized to a reliable external source or does not know whether its timezone information is correct. The element's parameters are still optional. That combination gives the sender a way to disclose a limitation without making every detail mandatory.

Three fields answer different questions

The parameters are optional. tzKnown says whether the originator knows its timezone information. That question is not answered by writing the timestamp in UTC: the appendix says the timezone may be known even when the timestamp is expressed as Z. A UTC timestamp therefore does not prove that the host's local timezone configuration is understood. RFC 5424 recommends conservative defaults and points to administrator configuration or checking before a sender asserts that the timezone is known.

isSynced records whether the originator considers itself synchronized to a reliable external time source, such as NTP. The message format does not interrogate that source. It transports the originator's value. That difference separates a signal from an observation: the receiver learns what the sender asserted, not what an independent monitor measured.

syncAccuracy, when present, is an integer number of microseconds expressing the maximum amount by which the originator thinks its clock could be off between synchronization intervals. It must not be sent with isSynced="0". RFC 5424's example uses 60,000,000 microseconds, or 60 seconds, and illustrates a 09:00 timestamp as potentially spanning 08:59 through 09:01. The example communicates a bounded expectation, not a third-party error measurement. The RFC says the value should be included only when the originator knows the reliability of its time source; its appendix says that knowledge is generally established through operator configuration and warns against creating a false impression of accuracy.

There is also a receiver-side consequence. If isSynced="1" appears and syncAccuracy is absent, RFC 5424 permits a collector or relay to assume the provided time is accurate enough to be considered correct. That rule gives the absence of a number a defined interpretation in that case. It does not turn the bit into a probe of the time service.

What a log pipeline can preserve—and what it cannot

The IANA registry lists timeQuality, tzKnown, isSynced and syncAccuracy as optional syslog parameters. That is consistent with a design in which senders may communicate confidence when they can support it, while receivers must cope with messages that do not carry the element. An absent element is not itself evidence that the event time is wrong; it is a limit on what the message tells the receiver.

For incident reconstruction, this distinction argues for keeping the structured-data element attached to the timestamp through collection, normalization and export. If a pipeline retains the time but drops its accompanying quality claim, a later analyst may see a precise-looking instant with less context than the originator supplied. If the pipeline preserves it, the analyst still needs to know which system asserted it, how that system was configured, and whether the monitoring record covers the relevant period.

RFC 8633's NTP Best Current Practice recommends monitoring time sources and NTP instances and detecting out-of-sync servers. That guidance is a useful operational counterpart: confidence should be supported by the health of the source and service, not by formatting alone. It does not establish that a particular syslog deployment monitors correctly, and no source here measures real-world adoption or error rates.

The boundary is the point

timeQuality is best read as evidence about an originator's declared timekeeping state. It helps a receiver avoid treating every timestamp as equally supported, and it gives operators a vocabulary for communicating known limits. It cannot prove event authenticity, settle causal order across systems, or establish that the declared source was actually healthy.

Heng Lu's Running-Code Primacy note offers a narrow editorial lens: written labels do not substitute for what deployed systems validate and run. Applied here, the RFC defines the report; the operational basis remains in the running originator's configuration and monitoring. A collector can preserve the claim and make it visible, but the claim's credibility has to be earned upstream.

Sources