Sekunde mal Java

Die Zeit in Java 8 – The Java Time-Scale

In der Dokumentation zu der Zeitpunkt-Klasse java.time.Instant [Instant] aus Java 8 findet man Folgendes:

... Java API defines its own time-scale, the Java Time-Scale.
The Java Time-Scale divides each calendar day into exactly 86400
subdivisions, known as seconds. These seconds may differ from the SI
second. It closely matches the de facto international civil time scale,
the definition of which changes from time to time.

Das klingt, als hätte es eine amerikanische Anwaltsfirma verfasst. Java verwendet als Einheit für die Zeit 86400 „subdivisions“ des Tages, die man Sekunden nennen könnte, welche aber manchmal keine Sekunden im Sinne des Internationalen Einheitensystems (SI) sind. Wie bitte? Das kann man ohne einigen Hintergrund nicht verstehen.

Der Zeitpunkt

Nach internationaler Übereinkunft (UNO, postal union usw.) definieren wir einen Zeitpunkt in einer komplexen Datenstruktur aus ganzen Zahlen mit den unterschiedlichen Basen 10, 24 (12) und 60:

• Jahr Monat Tag
• Stunde Minute Sekunde Sekundenbruchteile (ns)

Den Kalenderteil handhaben wir seit 1582 gemäß dem vom Papst Gregor XIII (Ugo Boncompagni, 1502-1585) eingeführten nach ihm benannten Kalender. Dieser wurde nicht von Papst Gregor erfunden, sondern vom genialen Astronomen und Mathematiker Aloysius Lilius (Luigi Giglio, 1510-1576) auf wissenschaftlicher Grundlage konzipiert. Giglio bringt den auf Sonnentagen basierenden Kalender und das auf dem Erdumlauf basierte Jahr für mehrere künftige Jahrtausende mit nur 0,002 Prozent mittlerer Abweichung in Übereinstimmung. Der Vorgänger, der Julianische Kalender, ging nach nur 16 Jahrhunderten schon um 10 Tage (fast 3 Prozent) mit stetig steigender Tendenz falsch.

Der Kalenderstandard von Luigi Giglio ist kurz, präzise und konsistent und hat diese Regeln:

• (0) Korrektur des Julianischen Fehlers: einmalig 1582 um +10
• (1) Das Jahr = 365d 5h 49m 12s (also fast 365,25 Tage)
• (2) Ein Normaljahr = 365d
• (3) Ein Schaltjahr (leap year) = 366d
• (4) Jahr hat 12 Monate: J31 F28/29 M31 A30 M31 J30 J31 A31 S30 O31 N30 D31
• (5) Jedes durch 4 teilbare Jahr ist ein Schaltjahr. (5a) Es sei denn, es ist durch 100, (5b) aber nicht durch 400 teilbar

Dank Luigi Giglio haben wir das Kalenderjahr auf absehbare Zeit gut im Griff. Und den Kalenderteil „Jahr.Monat.Tag“ beziehungsweise die Regeln 2 bis 5 des Standards sollte jeder algorithmisch beherrschen können.

Der Teil Tageszeit/Uhrzeit – Stunde Minute Sekunde – lebt traditionell noch mit Babylonischen 12er- und 60er-Zahlensystemen. Ein Tag hat 24 h zu 60 min zu 60 s, also 86400 s.

Anmerkung zur Regel 0: Die Übergangsregel interessiert für heutige Alltagszwecke kaum. Bei Kalenderberechnung in die Vergangenheit muss man sie berücksichtigen. Die Briten machten als Sonderweg erst mehr als 70 Jahre später mit und mussten ihren Kalender dann um 11 Tage korrigieren.

Anmerkung zur Regel 5: Enttäuschenderweise gab und gibt es Kalendersoftware ohne Implementierung der 100- und 400-Jahresregel. Da hatte man großes Glück, dass 2000 ein Schaltjahr ist. Ansonsten hätten wir als zusätzliches Jahr-2000-Problem manchen falsch gehenden beziehungsweise falsch gedruckten Kalender gehabt. Die Programmierer waren entweder Ignoranten, in dem Sinne, dass sie das, was die da behandelten (Zeit, Kalender), nicht kannten – oder sie verwendeten einfach die Formel des altehrwürdigen POSIX-Standards [POSIX], der bis zum Jahr 2001 die Jahrhundertregeln ignorierte.

Ein weiterer bei der Handhabung der ferneren Vergangenheit gern gemachter Fehler berücksichtigt nicht, dass die Geschichtswissenschaften von der Antike bis heute kein Jahr 0 kennen: „333 (v. C.) bei Issus Keilerei“ wäre vernünftigerweise -332. Ein Ausweg hier ist eventuell die sogenannte Julianische Tagesnummer JDN.

Die Sekunde

Lange Zeit war die Sekunde durch den mittleren Sonnen- beziehungsweise Sternentag astronomisch definiert. Die Zeit zwischen den Beobachtungsmöglichkeiten überbrückte man mit astronomischen Pendeluhren. 1890 gab serienmäßige „high end“ Pendeluhren für den Haushalt, die bei guter Auf- und Einstellung etwa 20 ms Abweichung pro Tag hatten. Doch die Entwicklung der Uhren ging weiter. Seit 1936 hatte die Physikalisch-Technische Reichsanstalt in Braunschweig – die Vorgängerin der PTB ebenda – Quarzuhren, die genauer waren als die übers Jahr gemittelte Erdumdrehung. Die Erdrotation hatte als Zeitnormal endgültig ausgedient.

Seit 1967 wird die SI-Sekunde hochpräzis von der PTB und entsprechenden anderen Instituten weltweit mit Atomuhren dargestellt und über Zeitsender wie DCF77, GPS usw. verbreitet. DCF77 zum Beispiel verbreitet die Zeit in der oben angegebenen Struktur Jahr Monat Tag Stunde Minute begleitet von Sekundentakten und einer hochpräzisen (von einer Atomuhr abgeleiteten) Sendefrequenz.

Die Nicht-Sekunde

Mit der „Java Time-Scale“ hat nun nicht nur Java, sondern auch andere Software von Oracle, Google und einigen anderen mehr eine von der SI-Sekunde abweichende „subdivision“ (s. o.) und stellt damit zeitweise eine Uhr mit 87 s Fehler pro Tag dar. Das können mechanische Uhren seit Hunderten von Jahren besser. Wer heutzutage mit einer Uhr mit 87 s Fehler pro Tag irgendetwas steuert oder misst, handelt fahrlässig und unter Umständen auch gefährlich.

Daher die wohl eingangs zitierte Aussage „Unser Dingsda (division) ist keine Sekunde im Sinne von SI“, die ja die Warnung „Wer’s dennoch tut, ist selbst dran schuld“ impliziert. Das Einzige, was da stimmt, ist die Zahl 86400 pro Tag. Bevor wir uns dem „Warum denn nun so was?“ zuwenden, schauen wir auf ein paar weitere Komplexitäten der Zeithandhabung in der IT. Und da macht Java (seit 8) alles richtig.

Zeitzonen

Vor der Einführung von 24 (26) Zeitzonen im 1-Stundenraster – UTC-11 .. UTC+12 (UTC+14) – dachte man in lokaler Zeit: Sonne im Zenit war 12 Uhr. Selbst ein 10-Minutenraster, wie Bristol = London - 10 min [WikiBri], war mit der rasanten Verbreitung von Eisenbahnen in den 1830er Jahren und erst recht mit der weltweiten elektrischen Kommunikation seit den 1860er Jahren nicht mehr praktikabel. Die Zeitzonen – zusammen mit klaren Datumsgrenzregeln – sind also ein Fortschritt.

Aber natürlich sind sie eine algorithmische Komplikation. Unsere Alltags-Datenstruktur Jahr Monat Tag Stunde Minute Sekunde ist ohne die Angabe der Zeitzone unvollständig. Ist diese Angabe falsch oder wird eine fehlende Angabe falsch impliziert, kann das schlimme Konsequenzen haben. So mussten Gerichtsverfahren zu Rechteverletzung oder Pornografie eingestellt werden, da die Zuordnung der schuldigen IP-Adresse zum Tatzeitpunkt teilweise um viele Zeitzonen falsch war.

Zeitzonen sind eine notwendige Komplikation (und damit Fehlerquelle). Notwendig sind sie, da die lokalen Uhrzeiten doch halbwegs zur Tageszeit passen müssen. 0 Uhr ist Nacht und 12 Uhr ist Tag. Der „Zonentag“ hat 24 Stunden, und die Zeitzonen sind semantisch in Ordnung.

Monotone sortierbare Zeitpunkte

Selbst mit richtiger Zonenangabe ist die Handhabung der Alltagsdatenstruktur unhandlich: Differenzbildung, Sortieren und weiter Operationen sind komplex und schwer nachvollziehbar. Die Angabe eines Zeitpunktes als Abstand zu einem festgelegten Nullpunkt in Sekunden (oder Nanosekunden) vermeidet diese Nachteile und Unwägbarkeiten. Der jeweilige Nullpunkt wird gerne „Epoche“ genannt.

Die Zeitangabe beziehungsweise der Zeitstempel bezogen auf eine Epoche ist schlicht eine Ganzzahl. Solche Zeitskalen können sich nur in Startzeitpunkt und Auflösung unterscheiden. Sind sie monoton, lassen sie sich mit einer einfachen linearen Transformation in einander umrechnen. Die verbreiteten Skalen zeigt Tabelle 1.

Die erwähnten linearen Transformationen zwischen solchen Skalen sind leicht herleitbar. Vom Windows-Dateizeitstempel zur Unix-Zeit beispielsweise gelangt man mit:

unixStamp = wFTstamp / 10000000 – 11.644.473.600;
wFTstamp = unixStamp * 10000000 + 116.444.736.000.000.000;

Der Faktor ist durch eine gegebenenfalls unterschiedliche Auflösung (s, ms, µs ns) bestimmt und somit eine Zehnerpotenz. Der konstante Offset stellt im Allgemeinen eine ganze durch 86400 teilbare Anzahl von Sekunden dar.

Über die oben genannte Voraussetzung der Monotonität sollte man eigentlich nicht nachdenken müssen. In unserer scheinbar vierdimensionalen Welt ist die Zeit das nicht-räumliche Kontinuum, in dem Ereignisse in offensichtlich unumkehrbarer Reihenfolge geschehen:

• Vergangenheit -> Gegenwart -> Zukunft
• Tempus fugit (lateinisch: „Die Zeit flieht“) und zwar kontinuierlich und monoton. Für die Umrechnung zwischen einer solchen Zeitskala und der Alltagsdatenstruktur benötigt man lediglich den Kalenderstandard von Luigi Giglio und die Zeitzonenangabe. Dies ist eine algorithmisch nicht ganz anspruchslose (als Übung sehr empfehlenswerte) Aufgabe. Für die Java-Zeit ist sie von Java 8 im Paket java.time perfekt gelöst.

Anmerkung zu Tabelle 1: Gibt man noch die Größe der Ganzzahl vor, hat man unter Umständen ein Problem: Die 32 Bit-Sekunden-Zeit von Unix hört 2038 auf. Javas vorzeichenbehaftete 64 Bit-Millisekunden hingegen umfassen das Alter des Weltalls.

Sommerzeit

Sommerzeit (SZ, summer time ST, oder day light saving time DST) ist eine Erfindung der deutschen Militärregierung Ludendorff/Hindenburg im Ersten Weltkrieg, um bei Tageslicht länger kämpfen und Munition herstellen zu können. Die allererste Verordnung zur Sommerzeit:

„Der 1. Mai 1916 beginnt am 30. April 1916 nachmittags 11 Uhr nach der gegenwärtigen Zeitrechnung. Der 30. September 1916 endet eine Stunde nach Mitternacht im Sinne dieser Verordnung.” Reichs-Gesetzblatt (Nr. 67, Jg. 1916), zitiert nach [MAR]

Für 1917 und 1918 galt diese Verordnung ebenso. Die USA folgten dem Beispiel. Hitler führte Entsprechendes 1940 ein – zu Ende ging das dann 1949 durch eine alliierte Verordnung.

Seit 1950 gab es keine Sommerzeit mehr, und kein Land erwog die Wiedereinführung, zumal sich die erwarteten Gewinne nicht eingestellt hatten. Leider kam mit der Ölkrise 1973 die Idee wieder auf und wurde mit unabsehbarem Ende eingeführt. Die Politikfolge war europäisch und international ein großes Durcheinander an Regelungen von keine Sommerzeit, +1/2 h, +1 h und +2 h sowie diversen Varianten von Umstellzeiten sowie kurzfristigen Ausnahmeverordnungen. Die EU und assoziierte Länder bekamen erst 2001 eine einheitliche Regelung – und das nur, weil alle anderen die Britische Regelung akzeptierten.

Die Folge der Einführung in den 70ern war ein Bruch der Semantik. Der Tag hatte nicht immer 24 Stunden, sondern auch mal 23 oder 25. Ein Sprung um eine (Uhrzeit-)Stunde dauert auch mal 0 oder gar 7200 s. Bei einer Anweisung:

timeXY += 86400;

weiß man nicht, ist

• A) „24 Stunden später“ oder
• B) „Selbe Uhrzeit am nächsten Tag

gemeint. Dies wurde im Allgemeinen nie dokumentiert oder spezifiziert, da es bis dahin (außer in zwei Weltkriegen) diesen semantischen Unterschied nicht gab. Java berücksichtigt ihn (ab 2014 mit Java 8) in java.time (s. Abb. 3). Die (hoffentlich?) monoton und genau laufende Clock (Normaluhr) bestimmt den Instant (Zeitpunkt). Der Abstand zwischen zwei Instants ist die Duration (Dauer nach Semantik A)). Die von ihren ZoneRules definierte TimeZone vermittelt die Umrechnung zwischen Instant und ZonedDateTime (Kalendertag plus Zonenuhrzeit) in beide Richtungen.

Die ZoneRules definieren auch die Zeitdauer Period, die einen Abstand in Tagen und Bruchteilen von Tagen zwischen zwei ZonedDateTime darstellt. Wird bei Anwendung oder Berechnung einer Period auf/aus zwei ZonedDateTime eine ungerade Anzahl von Sommerzeitumstellungen traversiert, wird der Abstand in Sekunden so korrigiert, dass man auf der entsprechenden Uhrzeit landet (Semantik B). Der durch die Einführung der Sommerzeit bewirkte Bruch der Semantik von „3 Tage später“ (z. B. in A) und B)) wurde von Java 8 also geheilt. Das hilft natürlich nur, wenn entweder klar spezifiziert oder nachträglich eindeutig nachvollziehbar ist, was davon gemeint war.

Die Erdrotation

Die Erdrotation ist, selbst im Jahresmittel, eine schlechte Uhr. Es gibt jährliche Schwankungen durch den Pirouetteneffekt der Wälder, unverstandene Schwankungen durch Änderungen von Magmaströmen sowie langfristig eine stetige Verlangsamung durch Gezeiten. Als Uhr ist die Erde instabil und sie geht im Mittel nach.

Nun gibt es eine lange Zeit – und teilweise bis heute – nicht hinterfragte Anforderung, UTC mit der Erdrotation (sprich mit Greenwich-Lokalzeit) in Übereinstimmung zu halten. Hierfür gibt es ein eigenes Erdrotationsbüro in Paris, das IERS.

Spätestens seit der Akzeptanz von Zeitzonen mit teilweise vielfach größerer Ausdehnung als 15° Länge oder gar dem jährlich zweimaligen effektiven Wechsel der Zeitzone (ST) gilt doch: Wo genau die Sonne um 12 Uhr steht, interessiert offensichtlich überhaupt nicht, solange man halbwegs die Tagesmitte trifft. Diese sekundengenaue Anpassung der Uhrzeit an die Erdrotation nicht zu hinterfragen oder aufzugeben, ist das eigentlich Unbegreifliche. Und es hat üble Konsequenzen. UTC und TAI – und alle jeweils darauf basierenden Skalen – sind nicht mehr gleich. Genauer gesagt, eine lineare Transformation mit den oben geschilderten Eigenschaften kann nicht mehr zwischen Skalen der beiden Sorten übersetzen.

Für die trotzdem gewünschte Anpassung der gemeinsamen Zeit (UTC) an die Erdrotation gab und gibt es zwei Varianten.

Anpassungsvariante 1: Die Definition der Sekunde ändern
Von 1962 bis 1972 wurde UTC auf +-1 s an die Erdrotation angeglichen:

• durch gelegentlich hinzugefügte Sekundenbruchteile (fractional leap seconds) und
• mit einer „Sekunde“, die länger als die SI-Sekunde (und die von TAI) war.

Das wollte von der Größenordnung her geringfügig sein, und in der IT hat es (damals) auch niemanden gestört. Rechner waren ja kaum vernetzt, die Sekunde wurde teilweise durch die schwankende Netzfrequenz dargestellt, und die Systemzeit gelegentlich nach der Armbanduhr des Administrators gestellt [Kamp11].

Dennoch wurde klar, dass man weltweite Navigation und synchrone Zeitsender nicht mit einer falschen, das heißt zu langsamen (und zudem ab und an leicht veränderten) Sekunde würde darstellen können. So wurde entschieden:

• Die UTC-Sekunde ist ebenso lange wie die TAI- und folglich die SI-Sekunde,
• UTC- und TAI-Sekunden ticken gleichzeitig.

Anpassungsvariante 2: Die Schaltsekunde
Hätte man es dabei (UTC = TAI - fester Offset) belassen, wäre nun alles gut. Die für UTC zuständigen internationalen Gremien (CCIR, ITU, BIPM) trafen, wohl auch auf Druck von Astronomen und Herstellern von astronomischem Navigationsgeräten, erst eine ungute Entscheidung – und machten dann dazu einen schlimmen Folgefehler.

Es wurde entschieden, nach Vorgabe des IERS (Erdrotationsbüro, Paris) Schaltsekunden in UTC an Monatsenden so einzufügen, dass UTC von der Erdrotation um weniger als 0,9 s abweicht. Es darf ein oder zwei positive oder auch negative (bei tendenziell zu langsamer Erde eher unwahrscheinlich) Schaltsekunden geben. Zwei Schaltsekunden (die bis dato auch nicht vorkamen) kann es bei Einhaltung der 0,9 s-Regel gar nicht geben. Allerdings beschränkt sich das IERS auf Schaltsekunden im Juni und im Dezember.

Bei einer positiven Schaltsekunde kann es also den folgenden Zeitpunkt als Ende des Monats Juni mit einer 61. Sekunde geben: 2015-06-30 23:59:60. Der 6. Juni 2015 hat also 86401 Sekunden. Der schlimme Folgefehler war, dass die UTC-Gremien die Schaltsekunde einerseits einführten und dieser dann andererseits den UTC- und in Folge den NTP-Zeitstempel verwehrten. Für die Zeitstempel wurde die Illusion 1 Tag = 86400 s aufrecht erhalten. Der Ablauf der Schaltsekunde Juni 2015 zeigt Tabelle 2.

Die Schaltsekunde hat keinen Zeitstempel oder sie recycelt den Stempel davor oder dahinter. Die Zeit als Folge der zonenunabhängigen Stamps bleibt stehen oder springt rückwärts: Die so dargestellte Zeit ist nicht mehr monoton und stetig.

Hätte der geniale Mathematiker Luigi Giglio in diesen Gremien Stimme und Gewicht gehabt, hätte es einen so inkonsistenten Standard nicht gegeben. Neben der Frage, wie so etwas beschlossen werden konnte, stellt sich die Frage, warum das in Fachkreisen so lange unbemerkt blieb beziehungsweise geduldet wurde.

Implementiert wurde für die eingeführte Schaltsekunde erst mal nichts. Bei Unix, MS-DOS Windows, Posix, Protokollen usw. wurde sie ignoriert: Alle Stunden haben 3600 s und alle Tage 84600 s. Die Computer waren ja unvernetzt und ihre Zeithaltung ungenau und häufig auch eh unstetig und nicht monoton – sprich oft von Hand nachgestellt. So machte sich niemand Sorgen, und die ersten 22 Schaltsekunden seit 1972 passierten weitestgehend unbemerkt und ohne dass Maßnahmen ergriffen wurden.

Fort mit der Schaltsekunde ! ?

Und damit das so blieb – so kann man nur vermuten –, überlegte sich die Erdrotation (nicht ihr Büro!) eine abgefeimte Bosheit: Sieben Jahre von Ende 1998 bis Ende 2005 blieb die mittlere Rotationsdauer konstant, und das IERS dekretierte keine Schaltsekunden. In dieser Zeit „passierte das Internet“ und am Ende hatten wir überall vernetzte Rechner und Automatisierungssysteme mit „atomgenau“ synchronisierten Uhren – vereinfacht gesprochen – sowie teilweise fortlaufende systemübergreifend vergleichbare Zeitstempel in teilweise µs-Auflösung für Ereignisse.

Als in dieser veränderten Lage eine neue Schaltsekunde für Dezember 2005 drohte, gab es in der betroffenen Fachwelt ernsthafte Sorgen. Diese mündeten Anfang 2005 in einem Antrag an die ITU zur Abschaffung der Schaltsekunde – und wenn es geht noch vor Dezember 2005 [Kamp11]. Nach fünf weiteren Schaltsekunden seitdem wissen wir: Das ging ja gar nicht und erst recht nicht so schnell. Dies von einer UN-Organisation zu erwarten, war wohl auch naiv.

Die Schaltsekunde 2005 führte ebenso wenig zu einer weltweiten Katastrophe wie der Jahrtausendwechsel 6 Jahre vorher. Es wurden aber viele Schwächen aufgedeckt, es gab Produktionsausfälle und gefährliche Situationen. Das Schweizer Zeitsignal (HGB75) war wohl auch ein paar Tage falsch.

Und seit 2017 lässt uns die Erdrotation schon wieder 6 Jahre ohne Schaltsekunde leben. Die Androhung der nächsten für Dezember 2022 scheint zwar zurückgenommen. Das Problembewusstsein hat so vielleicht schon wieder abgenommen, aber das Problem bleibt.

Die Lösung des Problems Schaltsekunde

Das Problem ist die Inkonsistenz des Standards:

• A) UTC sieht die Schaltsekunde vor.
• B) UTC und in Folge NTP stellen sie nicht dar. Deren Zeitskala ist so weder monoton noch stetig (und ergo eigentlich unbrauchbar).

Eine „echte“ Reparatur kann nur heißen:

• a) Entweder man schafft die Schaltsekunde endgültig ab. Alle Stunden dauern wieder 3600 s, und die Folge der Stamps ist ab dann wieder monoton.
• b) Oder man schafft die UTC = NTP Time Stamps ab und damit die Illusion, auch mit Schaltsekunden habe jeder Tag 896400 s. TAI Time Stamps wären die passende Alternative.

Die Reparatur b) wäre sehr komplex, da alle Software, die irgendwie Zeit handhabt, betroffen ist. So müsste in Java 8 eine neue (TAI) Instant-Klasse her und die ZoneRules müssten eine ergänzbare Liste der Schaltsekunden haben und bei der Umrechnung zwischen Instant und ZonendDateTime mit verarbeiten; vergleiche Abbildung 3. Das macht das Alles algorithmisch noch komplexer. Diese schon aufwendige Änderung ist per se machbar, sie wäre aber nur eine unter sehr sehr vielen.

Die Lösung a) ist zu bevorzugen, da sie ein künstlich geschaffenes Problem einfach und vergleichsweise kostenfrei beseitigt. Als Ersatz könnten die UTC-Gremien eine Schaltstunde für das Jahr 3000 vorsehen – sowie deren unmerkbare Realisierung als weggelassene Umstellung auf Sommerzeit.

Es ist klar, dass nur die Abschaffung der Schaltsekunde oder der konsequente Übergang zu Zeitstempeln mit TAI-Qualität der Weg aus der Inkonsistenz und damit eine Lösung ist. Alles andere kann nur ein Workaround (um höflicherweise nicht Murks zu sagen) sein.

Workarounds um die Schaltsekunde

Wenn man den eigentlichen Schaden nicht repariert bekommt, muss man das Problem irgendwie umgehen. Die grundsätzlichen Möglichkeiten sind:

• (1) nichts tun – und hoffen, dass nix passiert (oder nichts wissen)
• (2) die (Welt-)Uhrzeit 1 s oder 2 s stoppen oder vorwärts springen lassen
• (3) die Systemuhr in der letzten Stunde vor einer positiven Schaltsekunde um 1/3600 verlangsamen
• (4) die Systemuhr in den letzten 1000 s vor einer positiven Schaltsekunde um 1/1000 zu verlangsamen – und hoffen, dass keiner die um 1 ‰ zu langen Sekunden noch den Fehler der Uhrzeit um eine ganze Sekunde gegen Ende dieser Stunde bemerkt.

(1) war die „Lösung“ für einige Jahre nach Einführen der Schaltsekunde. Die Systemuhren wurden dann schon irgendwie und irgendwann nachgestellt.

(2) mit harten Sprüngen in die Vergangenheit oder Zukunft ist reale Science-Fiction. In Hollywoodfilmen führt es im Allgemeinen zu großem Wirrwarr und in der Realität auch – selbst wenn es „nur“ Zeitstempel sind.

(4) und (3) vermeiden die Nachteile von (1) und (2) durch einen weichen Übergang sowie durch die effektive Vermeidung der Schaltsekunde als reale Uhrzeit. Der Preis ist (zeitweise) eine (System-)Uhr mit einem Gangfehler von 87 s am Tag.

(4) ist der aktuelle Stand bei Oracle, Google, Java, im Internet und bei (Zeit-)Servern. Wenn die zuständigen Normungsgremien das eigentliche Problem nicht beseitigen, greifen die Akteure zu Workaround. Wenn sich alle großen Firmen auf einen gemeinsamen Stand einigen, ist das jedenfalls ein Vorteil.

Zusammenfassung

So ist nun der Bogen zur eingangs vorgeführten Nicht-Sekunde von Java 8 – und vielen anderen – gespannt. Über die implementierte (zeitweise) schlechte Uhr mit einem Gangfehler von 87 s pro Tag darf man lamentieren. Und so was ist ja vielfach unbrauchbar und damit schon problematisch.

Solange die Inkonsistenz des UTC-Standards mit seinen nicht-stetigen, nicht-monotonen Zeitskalen unrepariert bleibt, ist es – dank der Einigkeit der Akteure – ein weltweit für die meisten Clients unauffällig funktionierender einheitlicher Workaround.

Eine Dauerlösung kann auch das nicht sein. Nach maßgeblicher Meinung vieler Fachleute gehört die Schaltsekunde abgeschafft (Reparatur b) oben).

Die Argumente der Schaltsekundenbefürworter waren eigentlich immer schwach, nur hatten sie anfangs die Macht. Drei Beispiele:

• 1) Die Konsequenzen der Entkopplung der Uhrzeit von der Erdrotation um mehr als eine Sekunde könnte ungeahnte schreckliche Konsequenzen haben.
• 2) Eine Sekunde ist so kurz und damit egal; in der Zeitspanne passiert eh nichts.
• 3) Warum regt Ihr Euch über die Verstellung der Uhr um eine Sekunde so auf? Schließlich verstellen wir die Uhr zweimal im Jahr um eine Stunde.

Hier ist nur das erste Argument eines für die Schaltsekunde, die beiden andern behaupten ja nur, man könne sie (trotz Nutzlosigkeit) dulden. Wenn man beim ersten Argument nicht Aberglauben und Astrologie hinzuzieht, kann es sich nur auf astronomische Betätigungen (Beobachtung, „Zielen auf Himmelskörper“, Navigation nach Sternen) handeln. Hierzu muss man aber die Relation Erddrehwinkel(TAI) auf 10..20 ms genau haben mit allen Schwankungen im Lauf der Tage. Diese Daten zu liefern, ist Aufgabe des IERS. Die Genauigkeit innerhalb 2 s ist für die Astronomie und astronomische Navigation (im weitesten Sinne) eh völlig ungenügend.

Die Argumentation im Sinne von 2) gab und gibt es. Sie ist natürlich mit zahllosen Gegenbeispielen widerlegbar. Unter anderem bräuchte man dann diese präzisen Daten des IERS nicht.

Das Argument im Sinne von 3) bringt manches durcheinander. Zuallererst ist es ein Argument gegen die Schaltsekunde. Einer Menschheit, die in Zeitzonen von 15 bis 70 Längengraden Ausdehnung lebt und zum Teil die Uhr des Öfteren um eine Stunde verstellt, ist die Rolle der Erde als Stundenzeiger offenbar so egal, dass dessen Korrektur im Sekundenbereich schon lächerlich wirkt. Die Sommerzeitumstellung als Uhrverstellung um eine Stunde bricht natürlich die Semantik der Tageszeit/Tagesdauer der betroffenen Zone (siehe die Diskussion Duration vs. Period oben). Sie ist im Grunde genommen ein zweimal jährlicher Wechsel der Zeitzone mit allen organisatorischen und finanziellen Folgen. Die gemeinsame Weltzeit (UTC) bleibt davon unberührt. Die Schaltsekunde hingegen macht diese gemeinsame Basis kaputt. Und während die Sommerzeitumstellung durch lokale Regeln, in der Hoffnung, dass es da nicht stört, in die dunkle Nacht gelegt wird, passiert die Schaltsekunde weltweit gleichzeitig.

Weitere Informationen

[Instant] Java-Dokumentation (JavaDoc) der Klasse java.time. Instant (Javadoc), https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html

[JDN] Datum/Julianische Tagesnummer, https://de.wikipedia.org/wiki/Julianisches_Datum

[jtniehof] J. Niehof, Handle time when TAI second != UTC second, https://github.com/spacepy/spacepy/issues/393

[Kamp11] P.-H. Kamp, The One-Second War, in: CACM, May 2011, 44 ff., https://cacm.acm.org/magazines/2011/5/107699-the-onesecond-war/fulltext

[MAR] D. Kelimes, Wer hat an der Uhr gedreht? Die Einführung der Sommerzeit in Mannheim während des Ersten Weltkriegs, 27.3.2020, https://www.marchivum.de/de/blog/stadtgeschichte-4

[POSIX] History of IEEE P1003.1 POSIX time, https://www.ucolick.org/~sla/navyls/0400.html

[PTB] Die Sekunde, Physikalisch-Technische Bundesanstalt, https://www.ptb.de/cms/forschung-entwicklung/forschung-zumneuen-si/countdown-zum-neuen-si/die-sekunde.html

[Wiki4713] 4713 v. Chr., https://de.wikipedia.org/wiki/4713_v._Chr.

[WikiBri] https://en.wikipedia.org/wiki/The_Exchange,_Bristol

[WikiLo] Long Range Navigation, https://de.wikipedia.org/wiki/LORAN