Time Protocol (RFC 868)

How it works

Time can be carried over either a connection‑oriented or connectionless transport. The two modes differ only in framing and delivery; the time representation is the same in both:

• TCP mode: A client establishes a TCP connection to a server listening on port 37. The server writes a 4‑byte value (the seconds since the 1900 epoch) and then closes the connection. The client reads the 4 bytes and converts the big‑endian unsigned integer to a local time value. See protocol details in RFC 868.
• UDP mode: A client sends an (often empty) UDP datagram to the server's port 37. The server replies with a single 4‑byte datagram containing the same 32‑bit value. Because UDP is connectionless, there is no handshake or guaranteed delivery; the client may retransmit or fall back to TCP.

The transport protocols used are the common Internet transports: TCP for reliable byte streams and UDP for simple datagrams. The numeric value is encoded in network byte order (big‑endian), and the protocol provides one‑second resolution only.

Representation, limits and differences

The protocol's epoch begins at 1900‑01‑01 00:00:00 GMT. Because the format is a 32‑bit unsigned count of seconds, it can represent roughly 136 years of seconds before wrapping. That finite range creates a notable rollover issue in the mid‑21st century; systems relying on a 32‑bit time counter must be updated or replaced before wraparound affects correctness. The Time Protocol does not include timezone information, sub‑second precision, nor explicit support for leap seconds; clients must interpret the returned GMT value and apply local offsets as needed.

History, relationship to other protocols

The Time Protocol originated in the early development of the ARPANET and the Internet as a straightforward method for synchronizing clocks on hosts that needed only coarse alignment. Over time it was largely superseded by the Network Time Protocol (NTP), which provides higher precision, continuous synchronization, hierarchical time distribution, and mechanisms to correct for network delay and jitter. Nevertheless, the Time Protocol remains documented for legacy compatibility and simple use cases where one‑second resolution is sufficient.

Uses, examples and practical considerations

Typical uses of the Time Protocol have included bootstrapping system clocks, simple diagnostics, and embedding in lightweight devices or services where implementing the full NTP stack would be unnecessary. Common utilities historically used the port 37 service to set local system time. Because the protocol is unauthenticated and offers low resolution, it is unsuitable for security‑sensitive or high‑accuracy applications.

In practice, administrators should prefer more modern time synchronization methods for production systems. If the Time Protocol is encountered on a network, treat it as a legacy service: it can be useful for quick checks or constrained environments, but it provides no integrity, authentication, or compensation for network latency. For authoritative protocol details and behaviors consult the original specification at RFC 868 and refer to the transport standards for TCP and UDP.

Notable facts: the protocol's simplicity made it easy to implement on early hardware; its 4‑byte, big‑endian format is still used in some embedded systems today. However, the limited epoch and lack of modern features mean that most contemporary deployments migrate to NTP or Precision Time Protocol (PTP) solutions when precision or robustness is required.