Zusammenfassung

  • RFC 867 legte Port, Transport und Abschluss des Daytime-Dienstes fest, erklärte aber ausdrücklich, dass es keine bestimmte Syntax für das Datum gab.
  • Die zwei Muster waren verbreitete Darstellungen, keine Parser-Spezifikation. Für maschinell nutzbare Zeit verwies der Text auf das separate Time Protocol.
  • Der Fall trennt Lesbarkeit von semantischer Interoperabilität: Gültige Zeichen und ein erfolgreicher Austausch erlauben noch keine eindeutige Umwandlung in einen Zeitpunkt.

Zwei richtige Zeilen ohne gemeinsamen Parser

Ein Server sendet Monday, February 22, 1982 17:37:43-PST, ein anderer 02 FEB 82 07:59:01 PST. Menschen erkennen zwei Datumsangaben. Software braucht zusätzliche Regeln: zwei- oder vierstelliges Jahr, Bindestrich oder Leerzeichen vor der Zone, obligatorischer Wochentag, erlaubte Sprache und Vorrang bei einem Widerspruch.

RFC 867 erhob keines der Beispiele zum Pflichtformat. Nach der Feststellung, Daytime besitze keine spezifische Syntax, nannte das Dokument lediglich zwei populäre Formen. Ein Parser für eine davon implementiert eine beobachtete Konvention, nicht eine universelle RFC-867-Grammatik.

Damit kann der Transport erfolgreich sein, während die semantische Umwandlung offenbleibt. Die TCP-Verbindung entsteht und endet korrekt; das UDP-Datagramm kommt an; die Zeichen sind zulässig. Trotzdem ist nicht garantiert, dass unabhängige Clients denselben Zeitpunkt berechnen.

Was die zwei Seiten tatsächlich regelten

RFC 867 erschien im Mai 1983 und bezeichnete Daytime als Werkzeug für Diagnose und Messung. Bei TCP lauschte der Server auf Port 13, schickte nach dem Verbindungsaufbau Datum und Uhrzeit als ASCII-Zeichenfolge, verwarf empfangene Daten und schloss. Bei UDP beantwortete er jedes Datagramm an Port 13 mit Datum und Uhrzeit; der Anfragetext wurde ignoriert.

Empfohlen waren druckbare ASCII-Zeichen, Leerzeichen, Wagenrücklauf und Zeilenvorschub sowie genau eine Zeile. Das reichte für die unmittelbare Sichtprüfung und für eine einfache Begrenzung der Antwort.

Nicht festgelegt waren Feldfolge, Trennzeichen, Bruchteile, vierstellige Jahre, UTC-Bezug, Schaltsekunden, Sprache, Uhrgenauigkeit oder Herkunftsnachweis. „Aktuell“ war die Behauptung des Servers, kein Synchronisationszertifikat. ASCII begrenzte Bytes, nicht die Bedeutung des Kalenders.

Auch die registrierte Portnummer füllte diese Lücke nicht. Sie kennzeichnete den erwarteten Dienst, verlieh dem Betreiber aber keine Autorität über die bürgerliche Zeit und machte alphabetische Zonenabkürzungen nicht eindeutig.

Die Maschine sollte eine andere Tür nehmen

Am Ende verwies RFC 867 für maschinell nutzbare Zeit ausdrücklich auf RFC 868. Das Time Protocol gab auf Port 37 eine vorzeichenlose 32-Bit-Zahl der Sekunden seit Anfang 1900 zurück. Daytime lieferte eine lesbare Zeile auf 13; Time eine feste Größe auf 37.

Daytime war daher nicht bloß ein misslungener Serialisierungsversuch. Die menschliche Aufgabe war beabsichtigt. Ein Techniker konnte mit einfachsten Mitteln prüfen, ob ein Host antwortete, und dessen Uhr ansehen. Für Berechnungen stand der numerische Vertrag daneben.

RFC 880 katalogisierte Daytime im Oktober 1983 als elective: Ein Host durfte es implementieren oder weglassen. Time war recommended. Diese historische Einstufung misst keine heutige Verbreitung, dokumentiert aber die damalige funktionale Gewichtung.

Auch die feste Zahl hatte Grenzen bei Darstellung und späterem Ärakontext. Diese Analyse wiederholt nicht die bereits veröffentlichte NTP-2036-Geschichte; RFC 868 dient nur als der von RFC 867 selbst verlangte Gegensatz.

Der Wochentag, der nicht zum Datum passte

Das erste Beispiel bezeichnete den 22. Februar 1982 ursprünglich als Dienstag. Es war ein Montag. Der RFC Editor bestätigte 2025 Erratum 8551 und korrigierte das Wort. Das ist eine redaktionelle Berichtigung, keine Protokolländerung und keine Aussage über installierte Server.

Der Fehler zeigt dennoch präzise die Gefahr redundanter Angaben. Wochentag und Kalenderdatum beschreiben denselben Sachverhalt zweimal und können einander widersprechen. Ein Mensch bemerkt den Konflikt; ein Programm benötigt eine Vorrangregel. Daytime lieferte keine, weil es gar keine Parsing-Grammatik lieferte.

RFC 3339 formulierte dieses Problem später für Internet-Zeitstempel. Es ließ den Wochentag weg, verlangte vierstellige Jahre und einen erklärten UTC-Bezug mit numerischem Offset oder Z. Alphabetische Zonenbezeichnungen galten wegen schlechter Interoperabilität nicht als ausreichende Grundlage.

Eine direkte Nachfolge ist daraus nicht abzuleiten. RFC 3339 ersetzte RFC 867 nicht, und ein Erratum von 2025 verursachte kein Dokument von 2002. Vergleichbar ist die Architektur: Bei Daytime wählt der Server die Anzeige; bei RFC 3339 bleibt die Netzrepräsentation stabil und der Client lokalisiert die Darstellung.

Wie Menschenlesbares zur heimlichen API wird

Lesbare Protokolle senken Diagnosekosten, wie RFC 3339 selbst anerkennt. Doch ein natürliches Datumsformat in einem Land kann in einem anderen mehrdeutig sein. Weltweiter Austausch braucht deshalb eine Trennung zwischen Draht- und Anzeigeformat.

Solange ein Mensch Daytime betrachtet, ist die Freiheit nützlich. Sobald ein Skript die Zeile sammelt, einen regulären Ausdruck auf einen Server zuschneidet und nur den normalisierten Wert speichert, werden Zeichensetzung und Wörter zu einer undokumentierten API.

Der Betreiber kann die Darstellung ändern und vollständig RFC-867-konform bleiben, während der Verbraucher ausfällt. Das ist kein Standardverstoß des Servers, sondern die Folge davon, dass eine lokale Beobachtung zur nie gewährten Garantie erhoben wurde.

Belastbare Automatisierung bewahrt die Rohzeile als opaken Beleg oder vereinbart separat Syntax, Zone und Fehlerverhalten. Gestern erfolgreiches Parsen ist keine normative Zusage für morgen.

IANA-Registrierung ist keine Freigabe zur Exposition

IANA führt daytime weiterhin für TCP und UDP auf Port 13 mit RFC 867 als Referenz. Der Eintrag erhält die Bedeutung im Namensraum. Er beweist weder Betrieb noch Sicherheit, Richtigkeit oder die Pflicht zur öffentlichen Erreichbarkeit.

Die UDP-Variante verlangt eine heutige Betriebsentscheidung. Sie antwortet, ohne den Anfrageinhalt auszuwerten, während IP-Quelladressen fälschbar sind. RFC 8085 warnt allgemein vor kurzen unauthentifizierten Anfragen, die größere Antworten und damit Verstärkung auslösen, und empfiehlt je nach Kontext Begrenzung oder Authentisierung. Die Quellen messen keine heutige Daytime-Missbrauchsrate.

Die Frage lautet nicht, ob der Port standardisiert ist, sondern warum er erreichbar ist und welche Autorität seine Antwort erhält. TCP authentisiert keine Uhr, UDP keinen Anfragenden, und lesbarer Text keine Zeitwahrheit.

Wo ein kleiner Standard bewusst endet

RFC 867 machte Verbindung, Antwort und Abschluss vorhersehbar, bewahrte die Lesbarkeit und verweigerte das Versprechen einer Maschinengrammatik. Diese Zurückhaltung war ein Entwurfsmerkmal.

Für jede beobachtete Antwort lässt sich ein Parser schreiben. Entscheidend ist, ob der Standard sein Fortbestehen über alle konformen Server und Änderungen hinweg autorisiert. Bei Daytime tut er das nicht.

Interoperabilität hat Schichten. Der Port kann gemeinsam sein, obwohl die Datumsgrammatik es nicht ist. Zeichen können gültig, der Zeitpunkt aber mehrdeutig sein. Der Server kann konform bleiben, während die Automation scheitert. Ein Protokoll zu verstehen heißt auch zu wissen, welche naheliegende Schlussfolgerung es nicht erlaubt.

Quellen und Grenzen

Der Daytime-Vertrag steht in RFC 867, die Beispielkorrektur im Errata-Verzeichnis. Der Maschinenkontrast stammt aus RFC 868, die historische Einstufung aus RFC 880.

RFC 3339 liefert den späteren Vergleich; RFC 6335 und das IANA-Register begrenzen die Portbedeutung; RFC 8085 die moderne UDP-Nutzung. Aktuelle Verbreitung, Genauigkeit und Angriffe sind damit nicht belegt.