Leitfaden zur Server-Zeitsynchronisierung

UTC, TAI, GPS-Zeit und lokale Zivilzeit dienen unterschiedlichen Zwecken. TAI (Internationale Atomzeit) ist eine kontinuierliche atomare Zeitskala, die vom BIPM aus beitragenden Uhren berechnet wird; es fügt keine Schaltsekunden hinzu. UTC (Koordinierte Weltzeit) unterscheidet sich von TAI um eine ganze Zahl von Sekunden und ist die internationale Referenz für zivile Zeitzonen. GPS Time wurde bei seiner Einführung im Jahr 1980 an UTC angepasst, fügt jedoch keine Schaltsekunden hinzu.

Nach Angaben der U.S. Naval Observatory, Stand: September 2026 TAI beträgt 37 Sekunden und GPS-Zeit ist 18 Sekunden vor UTC. Diese Offsets können sich im Rahmen zukünftiger Schaltsekundenrichtlinien ändern.

Die BIPM-Definition der SI-Sekunde legt die ungestörte Grundzustands-Hyperfeinübergangsfrequenz von Cäsium-133 auf 9.192.631.770 Hz fest. Cäsiumuhren verwenden diesen atomaren Übergang als Frequenzreferenz.

Primärnormale und neuere optische Uhren haben unterschiedliche Messunsicherheiten; Eine einzelne Zahl „eine Sekunde in N Jahren“ kann nicht jedes Gerät beschreiben. Nationale Metrologieinstitute vergleichen ihre Standards und tragen zu internationalen Zeitskalen bei. Die Verteilung dieser Standards über NTP ist ein separater Prozess von der Browseranzeige von Clock-Tani, die keine direkte Verbindung zu einer Atomuhr herstellt.

Das Network Time Protocol (NTP) synchronisiert Computeruhren über Netzwerke. RFC 5905 (NTPv4) beschreibt eine Hierarchie von Zeitservern und eine Offset-Berechnung unter Verwendung von vier Zeitstempeln: Sende- und Empfangszeiten des Clients sowie Empfangs- und Sendezeiten des Servers. Ein Client kann diese Beobachtungen verwenden, um seine Systemuhr zu disziplinieren.

Die Leistung hängt von der Referenz des Servers, der Geräteuhr, der Netzwerkverzögerung und der Asymmetrie ab. Schnelle lokale Netzwerkbeispiele im RFC sind kein festes Genauigkeitsversprechen für das öffentliche Internet oder jedes Betriebssystem. NISTs Internet-Zeitdienst weist darauf hin, dass die von einem Benutzer angezeigte Genauigkeit weitgehend von der Netzwerkstabilität und Reziprozität abhängt.

Clock-Tani führt kein NTP im Browser aus und passt die Geräteuhr nicht an. Die Serverzeitseite schätzt die Differenz zu den Web-API-Antworten und zum Roundtrip-Timing.

Computer- und Telefonuhren hängen von Hardware-Oszillatoren und der Zeitmessung des Betriebssystems ab. Die Oszillatorfrequenz kann je nach Temperatur, Alter und Gerätedesign variieren, es gibt jedoch keine einheitliche Frequenz, tägliche Driftrate oder Synchronisierungsintervall, die für jeden Computer gilt.

Viele Betriebssysteme können ihre Uhr regelmäßig über einen Netzwerkzeitdienst anpassen, wenn dieser aktiviert und verbunden ist. Die Methode und der Zeitplan hängen von den Einstellungen und dem Gerät ab. Wenn ein Versatz unerwartet erscheint, überprüfen Sie die automatischen Zeit- und Zeitzoneneinstellungen. Behandeln Sie einen Browservergleich als eine Schätzung, die vom Netzwerk beeinflusst wird. NISTs FAQ zur Zeitmessung veranschaulicht, wie Quarzuhrfehler vom Oszillator abhängen.

Die standardmäßige Serverzeitseite stellt drei Anfragen an die API von Clock-Tani. Für jede Antwort wird die Hälfte der vom Browser gemessenen Roundtrip-Zeit zum Date.now()-Zeitstempel der API hinzugefügt und dann das Beispiel mit der mittleren Latenz ausgewählt. Dies verringert den Einfluss eines langsamen Ausreißers; es handelt sich nicht um eine NTP-Synchronisierung oder eine Genauigkeitszertifizierung. Das Zurückkehren zur Seite oder die Wiederherstellung der Netzwerkverbindung kann eine weitere Messung auslösen.

Für eine standortspezifische Ansicht sendet der Server eine HEAD-Anfrage an das Ziel, wenn ein aktuelles Ergebnis nicht bereits zwischengespeichert ist. Ein gültiger geschätzter Offset kann bis zu 60 Sekunden lang wiederverwendet werden. Es konsultiert den HTTP-Datumsheader und die Roundtrip-Zeit des Ziels und misst dann separat den API-Hop zum Browser. HTTP-Datum hat eine Auflösung von einer Sekunde. Fehlende oder unzuverlässige Header können zu einer anderen Quellen- oder Gerätezeit führen, die von der Schnittstelle unterschieden wird. Die Half-RTT-Korrektur geht von ähnlichen Ausgangs- und Rückgabeverzögerungen aus und kann keine feste Genauigkeit garantieren.

Nach den aktuellen UTC-Regeln werden bei Bedarf Schaltsekunden verwendet, um UTC nahe an der Erdrotationszeit (UT1) zu halten. Das IERS Bulletin C gibt bekannt, ob eine Schaltsekunde eingeführt wird. Eine positive Schaltsekunde kann 23:59:60 nach 23:59:59 in UTC eingefügt werden, was erfordert, dass Software mit einer ungewöhnlichen Minute umgeht.

CGPM-Resolution 4 (2022) fordert eine Erhöhung der zulässigen UT1-UTC-Differenz bis oder vor 2035 und die Vorbereitung eines Umsetzungsplans für eine kontinuierlichere UTC. Es wird weder eine bereits endgültige Anpassungsmethode für die Zeit nach 2035 festgelegt noch eine pauschale Zusage gemacht, dass die gesamte Schaltsekundenverarbeitung an einem bestimmten Datum endet.

Finanzmärkte, Luftfahrt- und Navigationssysteme, Telekommunikationsnetze und Stromnetze nutzen alle Zeitmessung, aber ihre erforderliche Präzision und Validierungsmethoden unterscheiden sich je nach Anwendung. Beispielsweise gibt die delegierte EU-Verordnung 2025/1155 über hochfrequente algorithmische Handelsaktivitäten eine maximale UTC-Abweichung von 100 Mikrosekunden für eine bestimmte Aktivität an; das ist keine universelle Regel für alle Branchen oder Branchen.

Für Satellitennavigation, Basisstationskoordination und Netzmessungen gelten eigene zeitliche Anforderungen. Eine auf Webantworten basierende Browseransicht wie Clock-Tani ist für diese Systeme keine validierte Uhr. Nutzen Sie für Folgeentscheidungen die offizielle Zeitquelle und Aufzeichnungen des jeweiligen Systems.

Öffnen Sie die Serverzeitseite, um die Uhr Ihres Geräts mit einer webantwortbasierten Clock-Tani-Schätzung zu vergleichen. Die Standardansicht nimmt bereits drei API-Beispiele und wählt das Ergebnis mit mittlerer Latenz; Durch eine dreimalige Aktualisierung werden diese Offsets nicht zu einem zertifizierten „echten“ Gerätefehler.

Die Seite zeigt einen geschätzten Millisekunden-Offset an, keinen gemessenen Round-Trip-Delay-Wert oder eine Diagnose des NTP-Status Ihres Betriebssystems. Verwenden Sie „Erneut synchronisieren“ nach einem Verbindungswechsel, wenn Sie eine andere Schätzung wünschen. Wenn ein dauerhafter Unterschied unerwartet erscheint, überprüfen Sie die automatischen Zeit- und Zeitzoneneinstellungen Ihres Geräts. Für diese Browsermessung gibt es keinen allgemeingültigen Schwellenwert für Normal/Vorsicht/Schwerwiegend, und ein Neustart ist keine allgemeine Voraussetzung vor einem zeitkritischen Ereignis.

Auf der Serverzeitseite von Clock-Tani wird neben der Gerätezeit eine auf Webantworten basierende Referenz angezeigt und deren Differenz geschätzt. Die Standardquelle ist der eigene API-Zeitstempel von Clock-Tani. Eine standortspezifische Ansicht kann den HTTP-Datumsheader des Ziels oder einen klar angegebenen Fallback verwenden.

Dieser Vergleich kann nicht feststellen, ob der NTP-Dienst Ihres Computers funktioniert, einen absoluten Fehler bestätigen oder die interne Öffnungszeit eines Ticketverkäufers überprüfen. Netzwerkverzögerungen und Servertaktfehler können sich darauf auswirken. Verlassen Sie sich bei Verkäufen, Prüfungen und anderen daraus resultierenden Fristen auf die offiziellen Ankündigungen und Einreichungsunterlagen des Veranstalters. Das Tool kann Ihnen dabei helfen, eine Referenz zu beobachten und erneut zu überprüfen, und es kann bis zu einer von Ihnen festgelegten Zeit herunterzählen.