Recognize the format and trust limits
05A small time reply is not a full clock-synchronization or security protocol. Its 32-bit format and source trust require care.
A received value does not prove correct time or an authenticated server. Delay and spoofing are not solved by the illustrated exchange.
Source for this drawing: RFC 868 · Read RFC source: The Time and service definition · pages 1–2 ↗
New to this? Start hereA quick picture + helpful background
Two clocks may disagree.
A device compares timestamps with another clock. Network delay makes that comparison imperfect. The drawing separates the clock reading from the trip the message takes.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Reading time is different from trusting or synchronizing it.
- The RFC explicitly says its 1900 base will serve until the year 2036. It defines no era field for selecting a later date range.
- The exchange defines no authentication, encryption or network-delay compensation fields; this is a limitation of the specified messages.
- NTP (RFC 5905) is a separate time protocol, not a formal update or obsoletion of RFC 868. This guide is for understanding legacy behavior, not deploying a new trusted time service.
The range drawing is schematic, not a complete rule for rollover or leap seconds. Do not silently assign a post-2036 era, set a system clock from an untrusted reply, or treat the listed Internet Standard status as evidence of modern security properties.
Read the RFC section ↗