Zusammenfassung

  • RFC 868 zählte Sekunden seit dem 1. Januar 1900 in einem 32-Bit-Wert und lieferte ihn über TCP oder UDP auf Port 37.
  • Der Standard gab die Grenze bis 2036 von Anfang an an. Der genaue Überlauf lässt sich berechnen, im Text steht aber nur das Jahr.
  • NTP entwickelte daraus keine unbegrenzte Zahl, sondern ein größeres System zur Synchronisierung und Äreninterpretation.

Zeit prüfen, nicht automatisch angleichen

Manche Systeme hatten 1983 keine Kalenderuhr; zudem konnten technische oder menschliche Fehler jede Uhr verfälschen. RFC 868 schlug eine kurze Abfrage mehrerer unabhängiger Stellen vor, um die lokale Zeit zu prüfen oder zu korrigieren. Sie legte ein gemeinsames Maschinenformat fest, nicht den vollständigen Ablauf einer Synchronisierung.

Gezählt wurde ab 00:00 GMT am 1. Januar 1900. Der Server lauschte an Port 37. Bei TCP stellte der Client eine Verbindung her; der Server sendete eine 32-Bit-Binärzahl und schloss wieder. Bei UDP schickte der Client ein leeres Datagramm und erhielt eines mit dem Wert zurück. Konnte der Server die Zeit nicht bestimmen, sollte er keine Zahl erfinden: Er konnte TCP ohne Wert ablehnen oder schließen und eine UDP-Anfrage unbeantwortet lassen.

Wie ein Rechner Laufzeit kompensiert, eine vertrauenswürdige Quelle auswählt, Antworten authentifiziert oder die lokale Uhr nachstellt, regelt RFC 868 nicht. Eine lesbare Zahl ist noch kein Nachweis ihrer Genauigkeit.

ASCII für Menschen, Binärwert für Maschinen

Die RFC 867 Daytime vom selben Monat sendete Datum und Uhrzeit als ASCII über Port 13, etwa für Fehlersuche und Messungen. Sie empfahl druckbare Zeichen, legte aber kein einheitliches Format fest. Ihr Hinweis verweist maschinelle Anwendungen an RFC 868. Die Standards unterscheiden Darstellung und Zweck, nicht die Qualität zweier konkreter Uhren.

Die Epoche 1900 lag vor dem üblichen Unix-Ausgangspunkt 1970. RFC 868 rechnet vor: 00:00 GMT am 1. Januar 1970 entspricht dem Wert 2.208.988.800. Mit gemeinsamem Ursprung lassen sich Zahlen vergleichen, sofern auch die Einheiten übereinstimmen.

Die kurze Darstellung hatte eine ausdrücklich benannte Laufzeit. RFC 868 sagte, die Basis werde „bis zum Jahr 2036“ dienen. Ein vorzeichenloser 32-Bit-Zähler erreicht 2³² Sekunden am 7. Februar 2036 um 06:28:16 GMT. Dieser Zeitpunkt folgt rechnerisch aus Ursprung und Feldbreite; RFC 868 nennt nur das Jahr. Die nächste Sekunde passt nicht mehr hinein, und der Zähler beginnt erneut bei null. Ohne zusätzlichen Zusammenhang kann ein Wert nach dem Überlauf einem Wert aus der ersten Runde gleichen.

NTP übernahm die Koordination

1985 bezeichnete RFC 958 NTP als Weiterentwicklung von RFC 868 und der ICMP-Timestamp-Nachricht sowie als geeigneten Ersatz für beide. NTP sollte mehrere Netzuhrwerke über verteilte Clients und Server synchronisieren. Das war mehr als die einzelne Antwort eines Servers.

NTP behielt den Ursprung 1900, ergänzte aber den Umgang mit Ären. Die spätere RFC 5905 beschreibt das 32-Bit-Sekundenfeld und den Übergang von Ära 0 zu Ära 1 im Jahr 2036. Ein Zeitstempel enthält zusätzlich einen Bruchteil; für die Zuordnung zur größeren Ära braucht es weiterhin Kontext. Eine ungefähre Kenntnis des aktuellen Datums kann Werte nahe dem Überlauf einordnen.

Der Nachfolger machte den alten Zähler nicht unbegrenzt. RFC 868 vereinfachte eine Abfrage und nannte den Zeitraum ihrer Basis. NTP nahm Synchronisierung und Äreninterpretation als größere Protokollaufgaben auf. Die Grenze stand bereits 1983 fest: 1900 ging ins Netz, doch eine Zahl allein kann nicht ewig sagen, zu welchem Zeitraum sie gehört.

Quellen und Grenzen

Hauptquelle ist RFC 868, Time Protocol vom Mai 1983. RFC 867 zeigt die damalige ASCII-Alternative, RFC 958 NTPs beschriebene Herkunft und RFC 5905 die spätere Ärenbehandlung. Daraus folgen weder Einsatzmengen noch Genauigkeit, flächendeckende Ablösung oder ein Ausfall im Jahr 2036.

Auch RFC 2626 warnt vor dem Überlauf 2036; die dort gedruckte genaue Minute weicht von der obigen Berechnung ab. Der Text nutzt RFC 2626 daher nur als Beleg für den damaligen Hinweis auf das Jahr, nicht für diese Uhrzeit (RFC 2626). Heng Lus Note 65 prägte die redaktionelle Frage, wie Implementierungen eine geschriebene Regel fortführen; sie ist Leselinse, kein historischer Beleg (Note 65).