Die zusätzliche Sekunde, für die Computer nie gebaut wurden
Atomuhren, das Fundament der modernen Zeitmessung, ticken mit unerschütterlicher Präzision. Die Erdrotation ist jedoch alles andere als konstant; sie verlangsamt und beschleunigt sich unvorhersehbar. Um diese Diskrepanz auszugleichen, wurden historisch gesehen Schaltsekunden in die Koordinierte Weltzeit (UTC) eingefügt, um sie innerhalb von 0,9 Sekunden zum himmlischen Rhythmus des Planeten zu halten.
Seit ihrer Einführung im Jahr 1972 wurden 27 positive Schaltsekunden hinzugefügt. Bei diesen seltenen Gelegenheiten schreitet die Uhr von 23:59:59 auf eine beispiellose 23:59:60 vor, bevor sie schließlich auf Mitternacht umspringt. Diese zusätzliche Sekunde stellt eine einzigartige Herausforderung für Computersysteme dar.
Unix time, ein grundlegendes Maß, geht im Grunde davon aus, dass jeder Tag genau 86.400 Sekunden enthält, und bietet keine native Darstellung für 23:59:60. Betriebssysteme wie Linux gehen traditionell damit um, indem sie eine Sekunde wiederholen, wodurch die Uhr effektiv zurückgestellt wird, um 23:59:59 zweimal abzuspielen.
Diese "nicht-monotone" Zeitanpassung, bei der die Wanduhrzeit kurzzeitig rückwärts zu laufen scheint, verletzt eine Kernannahme in unzähligen Softwareanwendungen. Solche Störungen haben wiederholt kritische Ausfälle ausgelöst, einschließlich des berüchtigten Reddit-Ausfalls im Jahr 2012, was die inhärente Zerbrechlichkeit eines Systems unterstreicht, das auf einer Sekunde aufbaut, für die Computer nie entworfen wurden.
Wie eine wiederholte Sekunde Reddit in die Knie zwang
Ein Paradebeispiel für diese Kaskade ereignete sich am 30. Juni 2012. An diesem Tag löste eine Schaltsekunden-Einfügung einen kritischen Fehler im Linux-Kernel aus. Anstatt sich elegant anzupassen, führte der hrtimer-Code des Kernels, der mit futex-Timern interagierte, dazu, dass Prozesse wiederholt und sofort aufwachten. Dies trieb die CPU-Auslastung auf 100 % und führte effektiv zu einem Deadlock der Systeme.
Reddit, eine große Online-Plattform, bekam die volle Wucht dieser subtilen Zeitanpassung zu spüren. Die Dienste waren für etwa 30–40 Minuten nicht verfügbar, was zeigt, wie eine einzelne, wiederholte Sekunde durch die Produktionsinfrastruktur wellenartig wirken und eine weit verbreitete Anwendung in die Knie zwingen kann.
Dieser Vorfall und andere ähnliche Ereignisse verdeutlichten eine grundlegende Lektion für das Engineering: Wall-clock time ist nicht immer monoton. Sie kann vorwärts springen, rückwärts gehen oder sich wiederholen, was der impliziten Annahme in vieler Software widerspricht, dass die Zeit immer linear verläuft.
Für robuste Systeme müssen Entwickler die Logik für verstrichene Zeit und Ereignisreihenfolgen so gestalten, dass sie nicht blind von time.Now() abhängen. Stattdessen sollten sie potenzielle Diskontinuitäten berücksichtigen. Dies beinhaltet die Verwendung von monotonic clocks für Dauermessungen und ein sorgfältiges Management von Ereignissequenzen, bei denen die Zeit rückwärts zu laufen scheint.
Cloudflares Negative-Time-Panic – und der Smear-Workaround
Eine andere Schaltsekunde am Neujahrstag 2017 legte das DNS von Cloudflare lahm. Ihr Go-Code berechnete DNS-Abfragedauern durch Subtraktion eines Start-Zeitstempels von einem End-Zeitstempel. Als die Uhr zurücksprang, ergab die Berechnung eine negative Dauer, die dann von einer Funktion empfangen wurde, die ein nicht-negatives Argument erwartete, was einen fatalen Panic auslöste.
Dieser Vorfall verdeutlichte einen grundlegenden Fehler: Viele Softwaresysteme gehen davon aus, dass die Zeit immer vorwärts läuft – eine Annahme, die durch die standardmäßige Anpassung der Schaltsekunde verletzt wird. Wie Cloudflare erklärte, wird die "wahrgenommene Auflösungszeit negativ", was zu unerwarteten Abstürzen führt. Weitere Details finden Sie unter How and why the leap second affected Cloudflare DNS.
Um solch abrupte Zeitsprünge zu umgehen, nutzen große Betreiber wie Google und Meta eine Technik namens Leap Smearing. Anstatt eine volle Sekunde auf einmal einzufügen, verlangsamen sie ihre Systemuhren über mehrere Stunden hinweg geringfügig und verteilen die zusätzliche Sekunde schrittweise. Dies stellt sicher, dass die Zeit für ihre internen Systeme niemals rückwärts zu laufen scheint.
Smearing vermeidet die scharfe Diskontinuität, die zum Absturz von Software führt, bringt jedoch eine neue Herausforderung mit sich. Verschiedene Organisationen verwenden möglicherweise unterschiedliche Smearing-Zeitpläne, was dazu führt, dass ihre Systeme bei der Uhrzeit vorübergehend voneinander abweichen. Dies erfordert eine sorgfältige Koordination der Zeitquellen, um die Konsistenz über die verteilte Infrastruktur hinweg aufrechtzuerhalten.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Schaltsekunden werden abgeschafft – aber die Zeit erfordert weiterhin Sorgfalt
Internationale metrologische Gremien haben nun beschlossen, die Schaltsekunde abzuschaffen; die Änderung soll bis spätestens 2035 vollständig in Kraft treten. Diese monumentale Umstellung erlaubt eine größere Abweichung zwischen der Coordinated Universal Time (UTC) und der Erdrotationszeit und beendet ein halbes Jahrhundert dieser störenden Anpassungen. Die Entscheidung spiegelt den wachsenden Konsens wider, dass die Risiken den Nutzen überwiegen.
Ein entscheidender Faktor für diese Änderung ist die jüngste, leicht beschleunigte Rotation der Erde. Dies warf das beispiellose Schreckgespenst einer negativen Schaltsekunde auf, bei der eine Sekunde von der UTC entfernt werden müsste. Eine solche Anpassung, die noch nie zuvor implementiert wurde, würde noch größere Herausforderungen für Software darstellen, die historisch gesehen bereits mit dem Hinzufügen einer Sekunde zu kämpfen hatte.
Für Entwickler bedeutet dies, dass die unmittelbare Bedrohung durch Schaltsekunden schließlich abnehmen wird, die grundlegenden Prinzipien einer robusten Zeitmessung jedoch bestehen bleiben. Verwenden Sie immer monotonic clocks für die Messung von Zeitspannen und Timeouts, da diese garantieren, dass die Zeit nur vorwärts läuft. Halten Sie zivile Zeitstempel, die oft an UTC gebunden sind, getrennt von Messungen der verstrichenen Zeit.
Überprüfen Sie abschließend alle Annahmen über das Verhalten von Uhren rigoros. Selbst ohne Schaltsekunden können Systeme immer noch auf folgende Probleme stoßen:
- Fehler bei der Zeitsynchronisation
- Netzwerklatenz
- Manuelle Uhrenanpassungen
Sorgfältiges Design und Validierung bleiben für zuverlässige verteilte Systeme von größter Bedeutung.
Häufig gestellte Fragen
Was ist eine Schaltsekunde?
Eine Schaltsekunde ist eine zusätzliche Sekunde, die gelegentlich zur UTC hinzugefügt wird, um sie grob mit der unregelmäßigen Erdrotation in Einklang zu halten.
Warum kann eine Schaltsekunde Software zum Absturz bringen?
Einige Systeme wiederholen oder passen eine Uhrsekunde an, was Software stört, die davon ausgeht, dass die Zeit immer vorwärts läuft oder dass jeder Tag genau 86.400 Sekunden hat.
Was verursachte das DNS-Problem von Cloudflare im Jahr 2017?
Eine rückwärtige Uhrenanpassung erzeugte eine negative Zeitspanne in einem Code, der einen nicht-negativen Wert erwartete, was einen Fehler in einer Zufallszahlfunktion auslöste.
Sollten Entwickler weiterhin monotonic clocks verwenden?
Ja. Verwenden Sie monotonic clocks zur Messung der verstrichenen Zeit; Wanduhren können weiterhin angepasst werden und eignen sich besser für Zeitstempel und Kalenderzeit.