Summary

  • RFC 867 fixed where and when a Daytime server replied, but explicitly defined no date syntax. Its two sample layouts were alternatives, not a universal parser contract.
  • The omission was deliberate: the RFC sent machine users to the separate Time Protocol, whose fixed 32-bit value traded readability for a common representation.
  • Later timestamp work formalized four-digit years, numeric UTC offsets and a narrow grammar. The lesson is not that readable protocols fail, but that display freedom and interchange authority cannot occupy the same field unnoticed.

Two correct replies, no common parser

Imagine receiving Monday, February 22, 1982 17:37:43-PST from one server and 02 FEB 82 07:59:01 PST from another. A person recognizes both as dates. A program immediately needs policy. Is the year two or four digits? Is the timezone separated by a hyphen or a space? Must the weekday agree with the calendar date? Could a server choose another language, omit seconds or add an offset?

RFC 867 made neither example mandatory. It called both popular syntaxes after stating that Daytime had no specific syntax. Therefore a parser written for one example is a parser for a local convention, not an implementation of a universal RFC 867 date grammar. The protocol can succeed at the transport layer while semantic conversion remains undefined.

That distinction is the story. Many protocol histories begin with a field whose meaning was tightly specified. Daytime is valuable because it standardized a useful interaction and then stopped. Its boundary tells us what the network promised, what the server retained and what a client was never entitled to infer.

A service small enough to explain in two pages

Published in May 1983, RFC 867 described Daytime as a debugging and measurement tool. The TCP form listened on port 13. Once a connection was established, the server sent the current date and time as an ASCII string, discarded anything received and closed the connection. The UDP form also listened on port 13. Any received datagram prompted an answering datagram; the request payload was ignored.

These rules were spare but real. A TCP client knew that connection close followed the answer. A UDP client knew it did not have to construct a meaningful query. Both knew to expect characters rather than a binary counter. The RFC recommended printable ASCII plus space, carriage return and line feed, and said the answer should be one line.

The document did not specify field order, separators, fractional precision, a four-digit year, a numeric UTC offset, leap-second notation, language, clock accuracy or provenance. “Current” named the server's claim, not a synchronization guarantee. “ASCII” constrained bytes, not the interpretation of the date they spelled.

This is why port registration and content meaning must be kept separate. Reaching the registered port shows that bytes arrived from an endpoint using that number. It does not prove that the endpoint's clock was right, that its timezone token was globally unambiguous or that the operator was an authority for civil time.

The adjacent protocol carried the machine contract

RFC 867 did not leave machine users without direction. Its final note said that machine-useful time belonged to RFC 868, the Time Protocol. RFC 868 returned one 32-bit unsigned count of seconds from the beginning of 1900. Daytime used port 13 and a readable line; Time used port 37 and a fixed quantity.

The contrast prevents an anachronistic judgment. Daytime was not necessarily a failed attempt at machine interchange. Its own text placed that responsibility elsewhere. A human could open a connection, see whether a remote clock answered and compare the displayed result without needing a protocol-specific decoder. A program that needed arithmetic could choose the numeric service.

The official protocol catalogue in RFC 880 sharpened the difference later in 1983. It listed Daytime as elective, meaning hosts could implement it or not, while Time was recommended, meaning hosts were encouraged to implement it. That historical status does not establish present deployment, but it records the intended hierarchy: the readable diagnostic was optional; the common machine value had broader operational importance.

The two services also expose opposite kinds of incompleteness. Daytime carries calendar words but no grammar. Time carries a compact scalar but no human presentation, timezone or later-era context. A protocol cannot maximize every property at once. The design question is which ambiguity belongs on the wire and which belongs at an endpoint.

An example that disagreed with itself

The first Daytime example originally labeled 22 February 1982 as Tuesday. It was Monday. RFC Editor erratum 8551, verified in 2025, corrected that word. The change is editorial, not a new protocol rule, and it says nothing about deployed servers. Yet the error is unusually apt evidence.

The sample contained both a weekday and a full calendar date. Those fields encode overlapping information, so they can contradict each other. A reader may notice. A parser must decide which statement wins. The RFC did not supply that conflict rule because it supplied no parsing grammar at all.

Nearly two decades later, RFC 3339 used exactly this class of problem when designing an Internet timestamp profile. It warned that redundant weekday information can fail to correlate with the date and therefore omitted the weekday. It also required generated dates to use four-digit years, required a stated relationship to UTC and standardized numeric offsets or Z rather than relying on alphabetic timezone abbreviations.

This is comparison, not lineage. RFC 3339 did not obsolete RFC 867, and the corrected example did not cause RFC 3339. The later document does, however, articulate the cost that Daytime willingly left outside its contract: machine interchange needs one bounded syntax and rules for ambiguity.

Readability moves; interchange stays put

RFC 3339 did not reject human readability. It praised readable protocols for making debugging cheaper, then noted that human date conventions differ across countries. Its settlement was architectural: send a stable wire form and let clients transform it for local display.

Daytime put the display decision at the server. That is convenient for direct inspection. It also means the server chooses the vocabulary, timezone token, precision and redundant fields. Once another program begins treating those choices as data, the server's presentation policy becomes an undocumented API.

This transition often happens without a design meeting. A diagnostic command is scraped into a monitoring script. A sample layout becomes a regular expression. A dashboard assumes every port-13 reply uses the same timezone abbreviation. The dependency works until an operator changes the format while remaining fully conformant to RFC 867.

The break is not standards noncompliance. It is evidence that the consumer promoted human output into a machine contract without obtaining authority for the promotion. Safe automation must either preserve the response as opaque text or establish a separate, explicit format agreement.

A registry entry is not an exposure instruction

IANA still records daytime for TCP and UDP port 13 and points to RFC 867. That is namespace evidence. It lets operators and tools agree on the intended service name. IANA's registry warning is equally important: assignment does not endorse an application or make traffic on that port legitimate.

The UDP form deserves a modern operating boundary. It answers a datagram without interpreting its contents, and an IP source address can be forged. RFC 8085 warns generally that unauthenticated short requests producing larger replies can be abused for amplification and recommends controls such as limiting responses or authenticating senders where appropriate. The sources do not establish a current Daytime abuse rate or universal amplification factor.

An operator should therefore ask why the service is reachable, not assume that an Internet Standard or registered System Port requires public exposure. TCP establishment does not authenticate the clock. UDP reachability does not authenticate the requester. A printable answer does not certify time.

The useful limit of a tiny standard

RFC 867's restraint remains instructive. It gave technicians a trivial way to inspect a remote host's claimed date and time. It made TCP and UDP behavior predictable. It kept the output convenient for eyes. And it drew a bright final boundary around machine use.

That boundary is easy to erase because software can parse almost anything once. The question is not whether a developer can write a regular expression for one observed answer. It is whether the standard authorizes that expression to keep working across conforming servers and future changes. For Daytime, it does not.

Internet interoperability is therefore not a single yes-or-no property. The port can interoperate while the payload does not. The characters can be valid while the instant is ambiguous. The server can conform while an automation breaks. A protocol is clearest when it says not only what the network guarantees, but also which tempting inference it refuses to support.

Sources and evidence boundary

The Daytime behavior and absence of syntax come from RFC 867, with its verified example correction in the RFC Editor errata record. The machine-readable contrast is RFC 868, and the 1983 status distinction is RFC 880.

Later timestamp-design evidence comes from RFC 3339. Port-governance context comes from RFC 6335 and the IANA service registry; modern UDP limits come from RFC 8085. These sources do not measure present deployment, accuracy or abuse, and they do not establish a direct succession from Daytime to RFC 3339.