Keine Schaltsekunde Ende Dezember 2026

• Laut IERS Bulletin C 72 wird UTC Ende Dezember 2026 keine Schaltsekunde hinzugefügt, sodass Zeitmess- und Verteilungssysteme keine gesonderte Einfügebehandlung vorbereiten müssen
• Die Differenz zwischen UTC und TAI bleibt ab 00:00 UTC am 1. Januar 2017 bis auf Weiteres bei UTC-TAI = -37 s
• Ob eine Schaltsekunde eingeführt wird, entscheidet sich anhand der Änderung von UT1-TAI; mögliche Termine sind Ende Juni oder Ende Dezember
• Bulletin C veröffentlicht alle sechs Monate einen UTC-Zeitschritt (time step) oder bestätigt, dass es zum nächsten möglichen Datum keinen Zeitschritt gibt
• Für die UTC-Verteilung Ende 2026 ist kein neuer Korrekturwert erforderlich; die bestehende Beziehung UTC-TAI = -37 s kann weiterverwendet werden

---

UTC-Mitteilung aus IERS Bulletin C 72

• Das von IERS am 6. Juli 2026 in Paris veröffentlichte Bulletin C 72 erklärt, dass Ende Dezember 2026 keine Schaltsekunde eingeführt wird
• Die Mitteilung richtet sich an Institutionen, die für Zeitmessung und -verteilung verantwortlich sind
• Die zwei zentralen Werte sind wie folgt
  • Ab 00:00 UTC am 1. Januar 2017 bis auf Weiteres gilt UTC-TAI = -37 s
  • Ende Dezember 2026 gibt es in UTC keinen neuen Zeitschritt

Entscheidung über Schaltsekunden und Mitteilungszyklus

• Schaltsekunden können abhängig von der Änderung von UT1-TAI in UTC eingeführt werden
• Mögliche Einführungszeitpunkte sind jedes Jahr Ende Juni oder Ende Dezember
• Bulletin C wird alle sechs Monate versendet
  • Wenn es in UTC einen Zeitschritt gibt, wird dies bekanntgegeben
  • Wenn es zum nächsten möglichen Datum keinen Zeitschritt gibt, wird dies bestätigt

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, woher diese Unvorhersehbarkeit kommt. Ich hätte gedacht, dass man Erdrotation und Umlaufbahn bis auf viele Nachkommastellen kennt. Ist die Vorhersage schwierig, weil Faktoren wie geologische Aktivität oder das Wetter Unterschiede in der Rotationsgeschwindigkeit verursachen?

  • Kurz gesagt: ja. Wetter, geologische Aktivität sowie vom Menschen verursachte Wasserverlagerungen wie das Erschöpfen von Aquiferen und der Bau von Staudämmen, dazu das Schmelzen von Gletschern und Eis, verursachen alle schwer vorhersehbare Veränderungen der Rotationsperiode und der Rotationsachse der Erde.
    Soweit ich mich erinnere, sind diese Modelle trigonometrische Polynome niedriger Ordnung; selbst wenn man die Unvorhersehbarkeit perfekt modellieren könnte, wäre eine Verteilung mit sehr hoher Genauigkeit wegen Abschneidefehlern schwierig, und sie sind bereits in Dingen wie Satelliten eingebaut, sodass man sie auch nicht beliebig komplex machen kann.
    Übrigens soll die Schaltsekunde bald verschwinden; soweit ich weiß, wird sie 2035 schrittweise eingestellt. Ich meine mich zu erinnern, dass es verzögert wurde, weil Russland Zeit brauchte, um die GLONASS-Satelliten zu aktualisieren.
  • Ja. Es gibt solche Faktoren und noch mehr. Unsere Messgenauigkeit ist viel besser als die jährlichen Änderungen erster und zweiter Ordnung der Tageslänge.
    https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... ist die dazu wohl relevanteste Grafik, und die vertikalen Sprünge stellen Schaltsekunden dar. Beim IERS gibt es auch Grafiken zu anderen Aspekten der Rotation, aber diese hier ist schön anzusehen.
  • Ich habe gerade den Wikipedia-Artikel nachgesehen, um zu schauen, wann die letzte Schaltsekunde eingefügt wurde, und die Antwort steht dort auch.
    „Die Rotationsgeschwindigkeit der Erde ändert sich als Reaktion auf klimatische und geologische Ereignisse, daher werden UTC-Schaltsekunden unregelmäßig eingefügt und können nicht exakt vorhergesagt werden.“
    https://en.wikipedia.org/wiki/Leap_second
  • Eher das Gegenteil. Die Erdrotation kann sich von Jahr zu Jahr sogar um mehrere Sekunden ändern, aber über Hunderte von Jahren gleichen sich die Schwankungen meist aus.
    Deshalb halte ich Versuche, Schaltsekunden hinzuzufügen oder zu entfernen, nicht für eine besonders gute Idee. In der Praxis kümmern sich eigentlich nur Raumfahrtbehörden um so etwas; sie können die gewünschten Korrekturwerte selbst anwenden, ohne alle anderen zu betreffen.
    Die einzige praktische Auswirkung dieses Drifts auf normale Menschen ist wohl GPS, aber GPS überträgt den Offset zu seiner eigenen Uhr ohnehin schon, sodass der Empfänger korrigieren kann. GPS-Zeit ist weder UTC noch TAI.
  • Siehe https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co...

• Ist das nicht eher Nicht-News? Ich meine mich dunkel zu erinnern, dass man die Einführung von Schaltsekunden ausgesetzt hat, bis es eine gesonderte Ankündigung gibt, weil sie in heutigen Computing-Systemen zu viele Probleme verursachen.
  Momentan beträgt die Differenz 37 Sekunden, und niemand muss sich Sorgen machen, dass Weihnachten in die Nähe von Ostern rutscht. Ich finde, dieses Problem kann man im Vergleich zu vielen anderen deutlich verantwortungsvoller an künftige Generationen weiterreichen.
  Dass alle sechs Monate eine Ankündigung kommt, ist doch nur ein Verfahren, um den Wortlaut des ursprünglichen internationalen Vertrags einzuhalten.

  • So weit ist es noch nicht. Es ist nur ein Vorschlag, und eine offizielle Abschaffung dürfte vor 2035 schwer werden.
    Der Grund, warum es eine Weile keine Schaltsekunden gab, ist, dass sich der Drift zwischen TAI und UT1 verlangsamt hat und sich tatsächlich sehr langsam in die Gegenrichtung bewegt.
  • Es wirkt absurd, dass die Ankündigungsfrist nur 6 Monate beträgt, und genau das könnte die Ursache des Problems sein.
    Wenn die Zeit um ±60 Sekunden falsch wäre, würde es niemand merken; es erschiene daher beherrschbarer, etwa alle zehn Jahre willkürlich eine Schaltsekunde einzufügen und das zehn Jahre im Voraus anzukündigen, damit alle genug Zeit haben, ihre Systeme zu bereinigen. Für eine weltweit koordinierte Umsetzung sind 6 Monate absurd optimistisch.

• Wenn man es einem Fünfjährigen erklären müsste: Welche Auswirkungen hat das auf UNIX-Zeitstempel? Besonders bei Systemen im Wartungsmodus oder solchen, die kaum noch betreut werden?
  Für meine Arbeit brauche ich diese Präzision nicht, aber es gibt sicher Bereiche, die sie brauchen.

  • UNIX-Zeitstempel ignorieren Schaltsekunden vollständig und behandeln sie so, als gäbe es sie nicht.
    Wenn also eine Schaltsekunde eingefügt wird, kann es eine physische Sekunde geben, die sich mit einem UNIX-Zeitstempel nicht referenzieren lässt, und wenn eine Schaltsekunde entfernt wird, kann es einen UNIX-Zeitstempel für eine Sekunde geben, die real gar nicht existiert.
  • Jedes Mal, wenn eine Schaltsekunde hinzugefügt wurde, ließ Google seine Serveruhren über einen längeren Zeitraum, normalerweise einige Stunden, langsamer oder schneller laufen, um sie allmählich wieder mit irgendeiner makellos weißen, perfekten kugelförmigen Standuhr aus reinem Platin beim NIST abzugleichen: https://developers.google.com/time/smear
  • Die Ergebnisse von time() und clock_gettime(CLOCK_REALTIME) werden von Schaltsekunden beeinflusst.
    Eine neue Schaltsekunde erreicht das System über NTP. Leider verteilt NTP nur ein Markierungs-Flag dafür, dass eine Schaltsekunde eingeführt wird, aber nicht den Offset selbst. Das muss der NTP-Client jedoch nicht unbedingt wissen, weil die verteilte Zeit selbst bereits von der Schaltsekunde beeinflusst ist.
    Andere Verfahren zur Zeitsynchronisation wie GPS und PTP verwenden dagegen Zeitskalen, die nicht von Schaltsekunden beeinflusst werden, und verteilen den UTC-Offset als Zusatzinformation. Die empfangene Zeit am Ende anzupassen, ist Aufgabe des Clients. Im Kernel gibt es dafür clock_adjtime()-Parameter für Schaltsekunden.
    Bei einem manuell betriebenen System mit NTP-Client wird die Zeit im laufenden Betrieb an die neue Schaltsekunde angepasst. Linux behandelt UTC-Zeit vorrangig, daher wird sie im RTC-Gerät gespeichert und bleibt auch nach einem Neustart erhalten.
    CLOCK_TAI sieht so aus, als müsste es TAI-Zeit zurückgeben, wird aber auf üblichen Linux-Desktop- und Server-Distributionen so stiefmütterlich behandelt, dass oft nicht einmal der Offset gesetzt ist und es daher dieselbe Zeit wie CLOCK_REALTIME zurückgibt.
    In /etc gibt es eine Datei mit einer Liste von Schaltsekunden, die zu irgendeinem Paket gehört; um diese Datei zu aktualisieren, ist ein Systemupdate nötig. Ich glaube nicht, dass traditionelle NTP-Software dieses Paket dynamisch aktualisiert. Allerdings gibt es auch nicht viel Software, die diese Datei verwendet.
    Wenn irgendein Init-Service-Skript diese Datei parst und damit den UTC-Offset des Kernels setzt, könnte CLOCK_TAI des Systems bis zum Update eine Sekunde hinter dem Rest der Welt zurückliegen. Soweit ich weiß, hat das aber keinerlei Auswirkungen auf die UTC-Zeit unter Linux.

• Die Formulierung „an die Institutionen, die für die Messung und Verbreitung der Zeit verantwortlich sind“ ist ein geradezu historisch großartiger Volltext

  • Noch besser ist, dass der Name dieser Organisation International Earth Rotation Service lautet
  • Über viele Jahre lautete der Titel der Führungskraft, die beim USNO verschiedene präzise Zeitprodukte beaufsichtigte, „Director of the Directorate of Time“
  • Klingt wie etwas aus einem Roman von Douglas Adams
  • „Director Earth Orientation Center of IERS Observatoire de Paris, France“
    Sogar der Titel klingt nach Science-Fiction

• Wenn der UTC-TAI-Offset bei -37 Sekunden bleibt, bedeutet das, dass auch der UTC-GPS-Offset bei -18 Sekunden bleibt
  Zwischen TAI und GPS gibt es einen konstanten Offset von 19 Sekunden

• Ich frage mich, was das für Systeme wie Spanner bedeutet
  Ist das ein Problem oder gar nichts Besonderes?

  • Ein großes Problem. Die gebräuchlichste Methode, damit umzugehen, heißt Smearing und passt über die 24 Stunden vor der „Schaltsekunde“ die Länge jeder Sekunde an
    In Systemen, die eine strikte Reihenfolge garantieren müssen, funktioniert das, weil jedes Gerät mit einer globalen Uhr synchron bleibt und sich nur die Länge des Taktzyklus minimal unterscheidet. Soweit ich mich erinnere, stand das sogar im ursprünglichen Spanner-Paper
    Seltene Systeme verwenden monotone Oszillatorsekunden und ignorieren Erdrotationssekunden, aber wenn man das irgendwann in reale Zeit umrechnen muss, sammelt sich mit der Zeit ein Desaster an, und allgemein gilt das nicht als gute Idee
  • Schaltsekunden werden nicht nach einem festen Plan wie Schalttage eingefügt, sondern hängen von physikalischen Messungen der Erde ab
    Deshalb dürften hochzuverlässige Systeme mit umfassendem Zeitmanagement von solchen Entscheidungen nicht stark erschüttert werden

• Wenn es die Temporal API gibt, können Browser oder Node.js die Zeit bei Berechnungen rund um diesen Zeitpunkt korrekt behandeln? Oder ist ein Update nötig, damit die Berechnungen nicht kaputtgehen?

  • Die Temporal API scheint auf Unix/POSIX-Zeitstempeln zu basieren, die Schaltsekunden ignorieren. In der Unix-Zeit hat ein Tag immer 86400 „Sekunden“
    Dadurch lassen sich UTC-Kalenderberechnungen für Vergangenheit und Zukunft auch ohne Datenbank einfach durchführen, und es ist nicht zwingend nötig, Bruchteile von Sekunden zu behandeln. Schaltsekunden werden vom Betriebssystem verarbeitet, indem es eine Sekunde wiederholt oder überspringt oder die Länge der Sekunden über einen gewissen Zeitraum vor oder nach der Schaltsekunde anpasst
    Die meisten Datums-/Zeit-APIs sind grundsätzlich so ausgelegt, dass sie Kalender- und Wanduhrberechnungen für Business-Funktionen unterstützen. Wenn man für wissenschaftliche Zwecke SI-Sekunden braucht, sollte man separate APIs und Funktionen verwenden, die bis auf Hardware-Ebene die nötige Semantik bereitstellen und garantieren
    Ebenso sollte man für Timer für Softwarefunktionen wie Thread-Sleep dedizierte Schnittstellen wie monotone Uhren verwenden. Auch wenn Schaltsekunden schrittweise verschwinden, ändert sich an dieser Lage nicht viel. Ob es Schaltsekundenanpassungen gibt oder nicht: Wenn etwa ein Mutex-Algorithmus von Unix-Zeitstempeln abhängt, war das schon früher falsch und bleibt auch künftig falsch

• Hört mir zu. Wir bauen Düsentriebwerke an den Äquator und drehen ihn um 180 Grad, um Zeit zu gewinnen oder zu verlieren. Und dann verbinde ich das mit meinem Snooze-Button

  • Wäre es für Superman nicht einfacher, mehrmals extrem schnell um die Erde zu fliegen? Dann müsste man sich keine Sorgen um die Wartung der Triebwerke machen
  • Tatsächlich könnte das Verschieben sehr großer Wassermengen einen messbaren Effekt haben. Zum Beispiel wenn man den Aquifer des California Central Valley erschöpft
  • Das Problem ist, dass eine zukünftige Gesellschaft diese Triebwerke für interstellare Raumschiffe abbaut. Dieses Problem wurde in einer Buchreihe von Larry Niven behandelt
  • Vielleicht müssten auch einfach alle gleichzeitig springen. Wir brauchen doch nur 1–2 Sekunden, oder?
  • Dass man eine Zeit lang keine Schaltsekunde einfügen musste, zeigt wohl, dass diese Methode funktioniert

• Dort steht: „Der Unterschied zwischen UTC und TAI ist seit 00:00 UTC am 1. Januar 2017 bis auf weitere Bekanntgabe UTC-TAI = -37s“
  Bedeutet das, dass die Atomuhr der Sonnenuhr um 37 Sekunden hinterherhinkt? Ich verstehe auch nicht, warum 2017 erwähnt wird

  • Eher fast das Gegenteil
    Ein UTC-Tag ist als genau 86400 SI-Sekunden definiert. Aber der tatsächliche mittlere Sonnentag ist ein paar Millisekunden länger. Wegen der Unregelmäßigkeiten der Erdrotation ist die Differenz nicht konstant, aber im Mittel wird erwartet, dass sie mit der Zeit langsam wächst. SI-Sekunden werden mit Atomuhren gezählt, daher springt UTC nach jeweils 86400 Sekunden der Atomuhr auf den nächsten Tag
    Eine Sonnenuhr dagegen, die den Tag jeweils dann weiterschaltet, wenn die mittlere Sonne den Mittag erreicht, schaltet einige Millisekunden später als UTC auf den nächsten Tag. Man muss die mittlere Sonne verwenden, weil sich die tatsächliche Sonne im Jahresverlauf mit unterschiedlicher Geschwindigkeit über den Himmel bewegt
    Anders gesagt: Jeder Zeitraum, den die Sonnenuhr genau 86400 Sekunden nennt, ist nach der Atomuhr ein paar Millisekunden länger
    Das summiert sich jeden Tag, bis es fast 1 Sekunde erreicht, und dann wird in UTC eine Schaltsekunde eingefügt, sodass dieser Tag nicht 86400, sondern 86401 Sekunden hat. UTC zählt nicht einfach nur Atomzeit, sondern muss auch mit der Sonne synchron bleiben, weil viele menschliche Aktivitäten mit der Position der Sonne am Himmel verknüpft sind
    Menschen haben „mit der Sonne synchron“ als „innerhalb von 1 Sekunde zur mittleren Sonne“ definiert. Das heißt, wir wollen, dass UTC-Mittag innerhalb von 1 Sekunde zum mittleren Sonnenmittag am Nullmeridian liegt
    Die 37 Sekunden bedeuten also, wie weit der mittlere Sonnenmittag dem UTC-Mittag hinterherhinken würde, wenn man keine Schaltsekunden verwendet hätte. Wenn UTC Mittag anzeigt, würde der mittlere Sonnenstand den Nullmeridian erst 37 Sekunden später erreichen
  • Laut Wikipedia wurde die letzte Schaltsekunde im Dezember 2016 eingefügt: https://en.wikipedia.org/wiki/Leap_second
  • 2017 wird erwähnt, weil sich der Offset damals zuletzt geändert hat. Deshalb ist -37 Sekunden seitdem durchgehend gültig