Summary

  • RFC 868 made Internet time machine-readable as one 32-bit count of seconds from 1 January 1900, returned over TCP or UDP at port 37.
  • The specification already said that base would serve only until 2036. The exact rollover instant follows from the field width; the RFC itself names only the year.
  • NTP grew from the Time Protocol into a synchronization system with era context. RFC 868’s single value and NTP’s clock coordination solve different jobs.

A question small enough for one reply

A host without a dependable date-and-time clock needed a way to check its own idea of the hour. RFC 868’s answer was intentionally direct: ask a time server, receive a number, and compare it with readings from other independent sites. Its opening paragraph names both the ordinary problem—some systems lacked a clock, and any clock could be wrong—and the useful network response: a brief poll of several sources.

The protocol did not send a formatted sentence. It specified a machine-readable count: the number of seconds since midnight GMT on 1 January 1900. The server listened on port 37. With TCP, a client connected and the server returned a 32-bit binary value before closing. With UDP, the client sent an empty datagram and the server answered with a datagram holding the value. If it could not determine the time, the server should provide no value: refuse or close the TCP connection, or discard the UDP request without replying.

That is a small contract, but it is not a clock-synchronization algorithm. RFC 868 explains why a host might poll multiple sites; it does not define how to estimate network delay, choose a trusted source, authenticate the reply, or discipline a local oscillator. A number can be machine-readable without being proof of accuracy.

One year, two services

The neighboring RFC 867 Daytime Protocol made a different trade. It sent the current date and time as ASCII on port 13, useful for debugging and measurement. It recommended printable characters but did not impose one exact date syntax. Its note directs machine-use cases to RFC 868. The distinction is not that one service knew the correct time and the other did not; the documents define different representations and uses.

RFC 868’s epoch also predates Unix time’s familiar 1970 origin. It even gives the conversion: 00:00 GMT on 1 January 1970 is the value 2,208,988,800 in its seconds count. Choosing a fixed origin made different machines’ values comparable, provided they interpreted the same epoch and units.

The specification did not hide the cost of its compact field. After defining the seconds count, it says the base “will serve until the year 2036.” The number of seconds in a 32-bit unsigned field reaches 2³² on 7 February 2036 at 06:28:16 GMT. That instant is arithmetic from the stated epoch and width, not a date printed by RFC 868. The next count cannot be represented in the same 32-bit range; values begin again at zero. Without outside context, a value on the far side of the wrap resembles one from the first era.

A sample became part of a larger clock system

Two years later, RFC 958 described the Network Time Protocol as evolved from RFC 868 and the ICMP Timestamp message, and as a suitable replacement for both. The mission had widened: NTP coordinates a set of network clocks through distributed clients and servers. It does more than return one server’s time sample.

NTP kept a connection to the 1900 prime epoch, yet its timestamp design had to account for eras. The later RFC 5905 explains the 32-bit seconds portion and the transition from era 0 to era 1 in 2036. The transmitted timestamp carries seconds and a fractional part; identifying the larger era still depends on context. RFC 5905 describes how nearby clock knowledge lets a client interpret the value around the wrap.

This lineage is not a story of one format simply becoming infinite. RFC 868 made a single query answerable with a small fixed value and stated its useful horizon. NTP took on synchronization and era interpretation as separate protocol problems. By 1983, the boundary was visible in the standard itself: the Internet had put 1900 on the wire, and the field had a date beyond which a bare count could no longer tell the whole story.

Sources and limits

The primary source is RFC 868, Time Protocol (May 1983). RFC 867 provides the contemporaneous ASCII-service contrast; RFC 958 records NTP’s stated lineage; RFC 5905 documents later era handling. These documents do not establish the number of deployed RFC 868 servers, the accuracy of any site, a universal migration, or a 2036 outage.

RFC 2626 also flags the 2036 rollover; its printed exact minute differs from the calculation above, so this article uses only its warning about the year, not that time (RFC 2626). Heng Lu’s Note 65 informed the editorial question about how implementations carry a written rule forward; it is a lens, not historical evidence (Note 65).