#137 Die Schaltsekunde und ihre IT-Folgen: Ein Sekundenbruchteil mit Impact

Eine (Schalt)-Sekunde kann für ganz schön viele Probleme sorgen

Alle 4 Jahre haben wir ein Schaltjahr, ein zusätzlicher Tag wird eingefügt. Was aber vielen nicht bekannt ist: Immer mal wieder gibt es auch eine Schaltsekunde. Auf einmal hat der Tag nicht 86.400 Sekunden sondern 86.401 Sekunden.

Und eine solch zusätzliche Sekunde kann, zumindest bei IT-Systemen, für eine ganze Menge Probleme sorgen. Und auch eine ganze Podcast-Episode füllen.

Wir sprechen über die Schaltsekunde und warum diese seit 1970 nur 27 mal eingefügt wurde.

Wir thematisieren die Probleme die eine zusätzliche Sekunde erzeugt,

Welche Lösungsmöglichkeiten es gibt, diese Probleme vorzubeugen, zB wie Windows damit umgeht, wann man eine monotonic Clock verwenden sollte, oder Warum Google und Amazon einzelne Sekunden in ihrem Zeit-Server verlangsamen und somit die Schaltsekunde “schmieren”.

Und wir sprechen über die Zukunft der Schaltsekunde, also ob wir diese noch brauchen oder nicht.

Es dreht sich also alles um Zeit bzw. um eine Sekunde.

Bonus: Du hast nur 27 Versuche, den Bug zu finden

**** Diese Episode wird gesponsert von easybill.

Suchst du nach einer neuen Herausforderung in einem spannenden, wachsenden Software-Team? Easybill kümmert sich um Rechnungserstellung für Freelancer und Händler auf Plattformen wie Ebay, Amazon oder Shopify und sucht Verstärkung im Bereich SRE sowie EntwicklerInnen für PHP, Ruby und etwas Rust. Arbeiten kannst du vollständig remote und mit modernen Technologien wie Kubernetes, Percona Cluster und mehr.

Klingt interessant? Schau doch mal unter https://easybill.de/jobs vorbei!

****

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:16) Was ist eine Schaltsekunde und wieso hat ein Tag 86400 Sekunden?

(00:03:54) Jobs mit Impact bei easybill (Werbung)

(00:05:55) Was ist eine Schaltsekunde und wieso hat ein Tag 86400 Sekunden?

(00:18:29) Welchen Einfluss hat eine zusätzliche Sekunde auf die IT?

(00:30:44) Probleme in der klassischen Software-Entwicklung

(00:33:26) Lösungen: Reboot, ignorieren und Smear-Second

(00:44:05) Die Zukunft der Schaltsekunde

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:03 - 00:01:12)

Herzlich willkommen zu einer neuen Episode vom Engineering Kiosk Podcast. Alle vier Jahre haben wir ein Schaltjahr. Ein zusätzlicher Tag wird eingefügt, was aber vielen nicht bekannt ist. Immer mal wieder gibt es auch eine Schaltsekunde. Auf einmal hat der Tag nicht Sekunden, sondern Sekunden. Und eine solche zusätzliche S kann zumindest bei IT Systemen für eine ganze Menge Probleme sorgen und natürlich auch eine ganze Podcast Episode füllen. Wir sprechen über die Schaltsekunde und warum diese seit 1970 nur 27 mal eingefügt wurde. Wir thematisieren die Probleme, die eine zusätzliche S erzeugt, welche Lösungsmöglichkeiten es gibt, diese Probleme vorzubeugen. Z.b. wie Windows damit umgeht, wann man eine Monotonic Clock verwenden sollte. Zweitausendein. Oder warum Google und Amazon eine einzelne S in ihren Zeitservern verlangsamen und somit die Schaltsekunde schmieren. Und wir sprechen über die Zukunft der Schaltsekunde, also ob wir diese überhaupt noch brauchen oder halt auch nicht. Es dreht sich also alles um Zeit bzw. Um eine einzelne S. Wir springen direkt rein. Los geht's. Viel Spaß.

Wolfi Gassler (00:01:16 - 00:01:19)

Andi, du glaubst gar nicht, wie ich mich jetzt auf diese Episode freue.

Andy Grunwald (00:01:19 - 00:01:25)

Da wir schon ein kleines Vorgespräch hatten, bin ich jetzt gespannt, was jetzt kommt, weil ich glaube, du lügst.

Wolfi Gassler (00:01:25 - 00:01:56)

Ich bin eigentlich so happy über diese Episode, weil du mir immer vorwirfst, so akademisch zu sein und mir auch immer vorwirfst, diese akademischen Programmierungen da und dass man irgendwelche Grundlagen versteht, das braucht doch in der Realität niemand. Und jetzt bist du mit einem Thema um die Ecke gebogen, was ja akademischer gar nicht sein könnte, würde ich fast sagen. Zweitausendein. Schlimmes Nerd Thema schlechthin. Und darum freue ich mich schon drauf, dir das jetzt vorwerfen zu können, dass du mit so einem Nerd Thema um die Ecke kommst. Erklär mal, was du da heute besprechen willst.

Andy Grunwald (00:01:56 - 00:02:34)

Also ich. Ich grinse gerade. Ich weiß nicht, ob man das in meiner Stimme hört, aber ich grinse gerade wirklich. Zwar das Thema. Ich hatte so viel Spaß, das Thema vorzubereiten. Und zwar geht es um Schaltsekunden, also um die sogenannte Leap Second und um sogenannte Schmiersekunden, also Smear Seconds. Und bei der Vorbereitung habe ich mich da so reingenerdet wie Kennt ihr das? Man macht ein YouTube Video auf und dann springt man zum nächsten und zum nächsten und zum nächsten und irgendwann ist man 3 Stunden drin und ist irgendwie so ein rabbit Hole so ganz tief runter. Und ich nach viereinhalb Stunden Episodenvorbereitung musste ich mich wirklich bremsen, weil ich bin so tief darunter in diesen Dax Bau, wenn man so möchte.

Wolfi Gassler (00:02:34 - 00:02:45)

Ich finde, du hast für eine läppische S dich viereinhalb Stunden vorbereitet und ich muss da abbrechen. Heißt Leap Second eigentlich läppische S? Ist es die eins zu eins Übersetzung?

Andy Grunwald (00:02:45 - 00:02:50)

Vielleicht die aus dem Ruhrpott? Das ist die läppische S, ja. Nee, das ist die Schaltsekunde.

Wolfi Gassler (00:02:50 - 00:03:04)

Ja, dann erklär mal was. Was ist eine Schaltsekunde? Ich kenne das Schaltjahr, dreht alle vier Jahre, oder? Glaube ich. Es wird schon peinlich. Ich weiß nicht mal, wann das Schaltjahr auftritt. Ich glaube alle vier Jahre. Wie oft tritt die Schalt s auf?

Andy Grunwald (00:03:04 - 00:03:06)

Klassische Beraterantwort. It depends.

Wolfi Gassler (00:03:07 - 00:03:10)

Ja, super. Es ist ja nur 1 s. Kann ich da schon dependen?

Andy Grunwald (00:03:10 - 00:03:27)

Nee, also ich muss mich bei dieser Episode jetzt ein bisschen konzentrieren, weil Ÿousand in Physik war ich noch nicht so wirklich gut damals in der Schule und in Astronomie, ich glaube, das hatte ich gar nicht als Fach. Deswegen, jetzt kommt der Erklärwerk. Also es geht jetzt so ein bisschen um Erdrotation und mittlere Sonnentage.

Wolfi Gassler (00:03:27 - 00:03:30)

Ich bin gespannt wie ein Regenschirm. Schieß los.

Andy Grunwald (00:03:30 - 00:03:32)

Wie viele Sekunden hat ein Tag?

Wolfi Gassler (00:03:34 - 00:03:36)

Oder nur, glaube ich, oder?

Andy Grunwald (00:03:36 - 00:03:45)

Nee, nee, wir nehmen 24 Stunden mal 60 Minuten mal 60 s Sekunden hat ein Tag.

Wolfi Gassler (00:03:45 - 00:03:58)

Kleine Zwischenfrage, wenn du das programmierst, machst du da immer 60 mal 60 mal 60 oder rechnest du dir das im Vorhinein aus und schreibst dann das Ergebnis hin? Andi, das Buch the Clean Coder von unserem Kollegen Uncle Bob sagt dir ja vermutlich was, oder?

Andy Grunwald (00:03:58 - 00:04:05)

Logisch, ist schon ein bisschen her, wann ich das gelesen habe, aber ist ja auch noch irgendwie so eine Art Pflichtlektüre in unserer Branche.

Wolfi Gassler (00:04:05 - 00:04:28)

Genau. Und was interessant ist, Easybill, unser Episodensponsor heute, war die erste Firma, die auf uns zugekommen ist, mit einem Werbetextvorschlag CleanCoder erwähnt hat. Und zwar haben sie CleanCoder verwendet, um Ownership für sich zu definieren, weil Ownership ist ja gerade in einem kleinen, wachsenden Software Team wichtig. Also du musst mitdenken, proaktiv sein, professionell handeln. Und genau so wird es in Cleancoder definiert.

Andy Grunwald (00:04:29 - 00:04:34)

Easy Bill, Easybill, irgendwas klingelt da bei mir. Hilf mir noch mal auf die Sprünge. Was machen die noch mal?

Wolfi Gassler (00:04:34 - 00:05:01)

Genau, du sprichst ja mit einem Freelancer und für mich sind die natürlich ein Begriff, weil die kümmern sich um die Rechnungserstellung, aber nicht nur für Freelancer, sondern auch für ebay, Amazon, Shopify Händler. Und die kennen sich ganz gut aus in dem ganzen Bereich e Rechnungspflicht, GoBD, also das Aufzeichnen von Unterlagen in elektronischer Form, Aufbewahrungsfristen und so weiter, was man da alles so beachten muss. Und du als Angestellter weißt es ja vielleicht nicht, aber als Firma muss man z.B. ab 2025 gesetzlich E Rechnungen empfangen können.

Andy Grunwald (00:05:01 - 00:05:07)

Und das wusste ich in der Tat nicht. Aber warum schaltet Easybill jetzt hier im Engineering Kiosk Podcast denn eigentlich Werbung?

Wolfi Gassler (00:05:07 - 00:05:23)

Ja, Easybill sucht Verstärkung für ihr Techteam. Einerseits SREs, um ihre Infrastruktur mit infraest Code zu managen, aber auch Entwickler innen im Bereich BHB, Ruby und ein bisschen Rust ist auch dabei. Und was das coole ist, das Ganze ist auch möglich vollständig remote.

Andy Grunwald (00:05:23 - 00:05:28)

Und wenn ich jetzt bei Easybill anfangen würde, mit welchem Infrastrukturstack würde ich denn dann arbeiten?

Wolfi Gassler (00:05:28 - 00:05:36)

Ziemlich breit das Ganze. Kubernetes, Bacona Cluster, TIDB, Mini IO und das ganze Blech, was sie verwenden, läuft bei Hetzner.

Andy Grunwald (00:05:36 - 00:05:40)

Das klingt auf jeden Fall nach einem kleinen, interessanten Team, wo man noch sehr, sehr viel Impact haben kann.

Wolfi Gassler (00:05:40 - 00:05:41)

Auf jeden Fall.

Andy Grunwald (00:05:41 - 00:05:51)

Wenn das nach einem Ort für deinen nächsten Karriereschritt klingt, zweitausendein, melde dich doch einfach mal bei Easybill. Alle infos findest du natürlich in den Shownotes oder unter Easybill de Jobs.

Wolfi Gassler (00:05:51 - 00:05:53)

Und jetzt zurück zu Podcast.

Andy Grunwald (00:05:53 - 00:06:14)

Ich habe beides schon gemacht. In der Regel mache ich 24 mal 60 mal 60. Und weil das klarer für die Programmierer ist. Ansonsten ist die 86400 so eine Magic Number. Und dann adde ich da einen Kommentar hin, was dann 24 Stunden mal 60 Minuten mal 60 s ist. Aber weil im Endeffekt bei kompilierten Sprachen ist es eh egal, weil das wird ja zur Compilezeit dann umgerechnet. Zweitausendein.

Wolfi Gassler (00:06:14 - 00:06:40)

Puh, ja, da erwartest du viel vom Compiler. Aber ich habe da auch immer ein schlechtes Gewissen, wenn ich sowas mache. Da denke ich mir immer, jetzt muss diese Computation, keine Ahnung, nimmt JavaScript her. Es muss jetzt auf jedem Rechner jede Person, die die Webseite aufruft, muss diese Berechnung von diesen vier Zahlen durchführen. Ist das nicht eigentlich schlecht für die ganze Welt? Aber ist ein anderes Thema. Okay, wir bleiben in den aber in dem Fall stimmt es nur manchmal ganz genau.

Andy Grunwald (00:06:41 - 00:07:12)

Und zwar bis 1967 dachte man, dass die Erde in einer gleichmäßigen Geschwindigkeit rotiert. Deswegen hat man die Definition einer S eins durch gemacht. Also der Bruchteil von eins durch eines mittleren Sonnentages. Ein mittlerer Sonnentag ist die Zeit, bis die fiktive mittlere Sonne nach einer kompletten Umdrehung wieder an der gleichen Stelle steht.

Wolfi Gassler (00:07:13 - 00:07:14)

Ich kann dir soweit folgen.

Andy Grunwald (00:07:15 - 00:08:14)

1967 hat man dann jedoch die Definition der S geändert. Warum, kommen wir gleich drauf zu. Seitdem her wird die S nicht mehr astronomisch anhand des mittleren Sonnentages definiert, sondern durch eine bestimmte Anzahl an Schwingungen eines Caesiumatoms. Daher kommt auch der Spruch internationale Atomzeit oder Atomuhr. Und die nennt man in Fachkreisen auch die international atomic time. Oder jetzt kommt etwas, was ich nicht aussprechen kann in französisch themes atomique international, ich weiß es nicht. Nennt sich abgekürzt TAi. Das bedeutet, immer wenn ihr irgendwo Tai im Kontext von Zeit lest, geht es um die Atomzeit zweitausendein. Der Riesenvorteil von diesem Atom es schwingt immer gleichmäßig. Der riesen Nachteil. Jetzt wissen wir, dass die Erde nicht gleichmäßig rotiert. Also haben wir jetzt eigentlich zwei Zeiten, die auseinanderlaufen. Einmal die astronomische Zeit und einmal die Atomzeit.

Wolfi Gassler (00:08:14 - 00:08:25)

Und wann hast du gesagt? 1969? 67. 67. Okay. Hat also nichts mit dem klassischen Unix Timestamp seit 1970 zu tun, dass der kurz danach eingeführt wurde.

Andy Grunwald (00:08:25 - 00:08:37)

Genau, war in dem Fall drei Jahre später. Zum Unix Timestamp kommen wir gleich auch noch. Fünf Jahre später, nachdem die Definition der S geändert wurde, wurde UTC eingeführt als koordinierte Weltzeit.

Wolfi Gassler (00:08:37 - 00:08:42)

Erst 1902 und siebzigste. Ja, darum kennt die Unix Timestamp keine UTC Zeit.

Andy Grunwald (00:08:42 - 00:09:59)

Das weiß ich schon wieder nicht. Also das ganze Thema Zeit ist so hart komplex. Wie gesagt, diese Frage, die kam mir gar nicht in den Sinn, und bei der Recherche musste ich abbrechen. Jetzt ist es aber so, Ÿousand, die Erde selbst, haben wir ja gerade gesagt, rotiert nicht gleichmäßig. Und jetzt haben wir die Definition der s geändert auf Basis des Caesiums Atoms. Die Erde rotiert minimal langsamer, als bei der Definition der S zugrunde gelegt wurde. Tatsächlich ist ein mittlerer Sonnentag dauert um Sekundenbruchteile länger als Sekunden. Das bedeutet, ein mittlerer Sonnentag dauert ungefähr zwei Millisekunden länger als noch vor 100 Jahren. Das und wirklich, das ist der Grund, warum es eine Schaltsekunde gibt, oder bzw. Ab und zu eine Schaltsekunde eingeführt wird, damit die koordinierte Weltzeit UTC mit der auf der Erdrotation basierenden Weltzeit möglichst synchron gehalten werden kann. Und die Erdrotation basierende Weltzeit heißt UT. Also jetzt sind wir schon bei drei einmal der Atomzeit THi, einmal der koordinierten Weltzeit UTC und einmal der Erdrotation basierten Weltzeit UT.

Wolfi Gassler (00:10:00 - 00:10:08)

Das heißt, die Schaltsekunde ist plus 1 s. Das heißt, die Uhr bleibt im Prinzip 1 s stehen, oder? Also pausiert 1 s.

Andy Grunwald (00:10:09 - 00:10:50)

So, jetzt muss ich mich ganz kurz konzentrieren, weil das ist nämlich echt ein harter Brainfuck. Ja, wir haben eine positive Schaltsekunde, also plus eins. Und der Grund ist folgender. Ein tatsächlicher mittlerer Sonnentag, also astronomische Uhr Erdrotation braucht einen Sekundenbruchteil länger als 24 Stunden. Also er braucht Sekunden und ungefähr zwei Millisekunden. Die koordinierte Weltzeit UTC basiert auf der Atomuhr. Und die Atomuhr, dieses Cesiumatom, diese Schwingungen, die sind gleichmäßig. Und deswegen ist ein Tag bei der Atomuhr immer 400 s.

Wolfi Gassler (00:10:50 - 00:10:59)

Also einfach die zwei Millisekunden, die da jedes Jahr dazukommen, die muss man dann einfach einmal eben mit plus einer S dazuzählen bei der klassischen Zeit.

Andy Grunwald (00:10:59 - 00:11:34)

Genau. Nur dass sie nicht jedes Jahr dazu kommen, die zwei Millisekunden, weil es geht ja um die Erdrotation. Die Erdrotation findet ja eigentlich jeden Tag statt. Aber da die Erdrotation halt nicht periodisch ist, also sie ist nicht gleichmäßig, kommen ab und zu mal Ÿousand zwei Millisekunden hinzu, ab und zu mal 1,5, ab und zu mal 2,5 und so weiter. Und was gemacht wird ist, es wird so lange gewartet, bis die Zeitdifferenz von der astronomischen Uhr und der Atomuhr knapp größer 0,9 s ist und dann wird entschieden, ah, bald kommt eine Schaltsekunde, eine positive Schaltsekunde.

Wolfi Gassler (00:11:35 - 00:11:40)

Moment, aber wer entscheidet? Sitzen da Leute oder ist das berechnet oder?

Andy Grunwald (00:11:40 - 00:11:49)

Ja, wir wären ja nicht die Welt, wenn wir dafür nicht eine Zuständigkeit haben. Und zwar gibt es den internationalen Dienst für Erdrotation und Referenzsysteme.

Wolfi Gassler (00:11:49 - 00:11:51)

Eh klar, er ist sicher in Deutschland, oder?

Andy Grunwald (00:11:52 - 00:12:05)

Ne, wo die sitzen, weiß ich gerade nicht. Es ist auf jeden Fall eine internationale Organisation zur Messung und Berechnung der Erdrotationsparameter und eines Bezugssystems für astronomische und geographische Positionsdaten. So, und jetzt kommt's.

Wolfi Gassler (00:12:05 - 00:12:05)

Zweitausendeinundzwanzig.

Andy Grunwald (00:12:05 - 00:12:36)

Das ist jetzt diese internationale Organisation. Wir könnten das jetzt noch viel weiter komplizierter machen. Die gesetzliche Zeit, also ob dein Land sich an die Schaltsekunde hält oder nicht, entscheidet das Land. Aber selbst Deutschland, Österreich und die Schweiz z.b. halten sich aber an diesen Dienst für Erdrotation und Referenzsysteme. Also die sind dafür zuständig zu überwachen, dass die astronomische Zeit von der Atomzeit, von der koordinierten Weltzeit nicht größer als 0,9 s abweicht. Und die geben bekannt, wann dann die nächste Schaltsekunde eingefügt wird.

Wolfi Gassler (00:12:36 - 00:12:47)

Zweitausendein. Aber was jetzt noch nicht ganz verstehe, wenn du sagst zwei Millisekunden pro Jahr, dann bräuchtest du da ja irgendwie pro Tag, pro Erdrotation. Pro Tag ist zwei Millisekunden.

Andy Grunwald (00:12:47 - 00:12:50)

Genau. Jeden Tag rotiert die Erde einmal rund. Weil sonst haben wir dann.

Wolfi Gassler (00:12:50 - 00:13:11)

Ist es pro Jahr dann schon einiges. Summiert sich da schon einiges zusammen. Dann hast du ja schon wie viel Tage hat dieses Jahr dann hast du ja schon 600 Millisekunden oder so pro Jahr oder 700 eigentlich oder irgend so was. Also dann bist du schon fast bei einer Schaltsekunde pro Jahr. Oder eben so irgendwie alle eineinhalb Jahre, oder?

Andy Grunwald (00:13:12 - 00:13:49)

Also ja und nein. Du fragst ja jetzt gerade mehr oder weniger durch Die Blume, wann findet eigentlich so eine Schaltsekunde statt? Ich habe ja gerade gesagt, die Differenz darf nicht mehr als 0,9 s betragen. Aber die offizielle Antwort ist bei Bedarf. Denn die Rotationsgeschwindigkeit der Erde ist halt nicht periodisch. Also es bedeutet, sie weist nicht periodische Unregelmäßigkeiten auf. Und das wiederum bedeutet in dem Fachjargon, muss ich auch extra googeln, es ist nicht verrauchsrechenbar. Also es ist nicht möglich, technische Systeme so zu programmieren, um die Schaltsekunde wirklich hervorzusagen. Denn die Erdrotation hängt halt von vielen Faktoren ab. Unter anderem.

Wolfi Gassler (00:13:50 - 00:13:58)

Jetzt erzählen wir aber nicht, dass dieser Mythos mit den Regenwürmern stimmt, wenn ein paar Regenwürmer in die falsche Richtung alle krabbeln oder so, dass die Erde langsamer läuft.

Andy Grunwald (00:13:58 - 00:14:17)

Den Mythos kenne ich nicht, den wird vielleicht in österreichischen Schulen erzählt oder so. Hier auf jeden Fall nicht. Aber die Geschwindigkeit der Erdrotation wird unter anderem von der Gravitationswirkung vom Mond beeinflusst. So, und da verlässt mich dann meine Astronomie und Physikkenntnis.

Wolfi Gassler (00:14:17 - 00:14:19)

Da sind wir ja schon fast in der Astrologie dann.

Andy Grunwald (00:14:19 - 00:14:40)

So, jetzt reden wir ja die ganze Zeit davon, Achtung, wo wir gerade bei Erdrotation sind. Jetzt reden wir ja die ganze Zeit davon, wir fügen 1 s hinzu, weil wir sagen, die astronomische Zeit läuft einen Tick länger als Sekunden. Im Jahr 2020 drehte sich die Erde aber sogar etwas schneller als die Definition.

Wolfi Gassler (00:14:41 - 00:14:45)

Der s, weil die Regenwürmer alle in die gleiche Richtung gekrabbelt sind. Ich sag's dir.

Andy Grunwald (00:14:45 - 00:14:47)

Was bedeutet das, Wolfgang?

Wolfi Gassler (00:14:47 - 00:14:49)

Dass wir 1 s abziehen müssen?

Andy Grunwald (00:14:49 - 00:14:52)

Dann reden wir von einer negativen Schaltsekunde.

Wolfi Gassler (00:14:52 - 00:14:58)

Und Moment mal, und das kann unser System irgendwie. Das war zum ersten Mal, oder es.

Andy Grunwald (00:14:58 - 00:15:45)

Ist überall vorgesehen, zumindest in der Literatur, dass es eine negative Schaltsekunde geben kann. In der Praxis gab es die noch nie. Lass uns mal ganz kurz darüber sprechen, wann oder beziehungsweise wie eine positive Schaltsekunde eingeführt wird. Erstmal als Grundregel, Eine Schaltsekunde wird immer am Ende eines Tages eingefügt oder abgezogen. Das bedeutet, wir reden immer von der h 23, wir reden immer von der Min 59. Und jetzt reden wir entweder von der S 58, s 59 oder s 60. Und zwar sagen wir eigentlich, die Uhrzeit springt von 23 Stunden 59 Minuten 59 s auf 0 Uhr. Richtig?

Wolfi Gassler (00:15:45 - 00:15:53)

Ich habe mir das noch nie so überlegt, Ÿousand. Ja, wahrscheinlich auf oder auf. Na, wahrscheinlich auf. Von 5,9 auf.

Andy Grunwald (00:15:53 - 00:16:06)

Genau. Bei einer positiven Schaltsekunde, wenn wir also die koordinierte Weltzeit wieder an die astronomische angleichen und 1 s hinzupacken, dann gibt es die Uhrzeit 23 Stunden 59 Minuten, 60 s.

Wolfi Gassler (00:16:07 - 00:16:39)

Das heißt, um endlich mal was informatisches reinzubringen, wobei Zeit wahrscheinlich auch Informatik ist, wenn man es breit sieht. Aber wenn ich jetzt einen Eintrag anlege, Ÿousand, genau. In dieser S, in dieser Schaltsekunde, dann ist es bei Computersystemen, die das unterstützen, ist es noch am ersten Januar oder am ein und dreiigster Dezember angelegt worden. Und bei anderen Computern, die die Schaltsekunde dazufügen, ist es am ersten Januar angelegt worden. Oder umgekehrt eigentlich. Also die, die es nicht unterstützen, ist schon im neuen Jahr, und die, die es unterstützen, ist es noch im alten Jahr.

Andy Grunwald (00:16:39 - 00:16:41)

Korrekt. Du springst also in der Zeit.

Wolfi Gassler (00:16:42 - 00:16:50)

Ja, vor allem zwei Computer können unterschiedliche Werte abspeichern eigentlich. Das ist ja das größte Problem, wenn sie nicht demselben Muster folgen.

Andy Grunwald (00:16:50 - 00:16:52)

Ja, ich meine, da redest du ja schon von Zeitsynchronisation.

Wolfi Gassler (00:16:52 - 00:16:57)

Und wie funktioniert das bei der negativen? Da bleibt die Uhr irgendwie stehen, oder?

Andy Grunwald (00:16:57 - 00:17:22)

Nein, da wird ganz einfach offiziell 1 s übersprungen. Da gibt es dann für den Augenblick die 23. H, 59. Min und die 59. S nicht. Da wird direkt von der 58 s auf gesprungen. Zweitausendein, weil die negative Schaltsekunde besagt ja den Ausgleich der Synchronisation, weil die Erde sich für lange Zeit schneller als Sekunden gedreht hat.

Wolfi Gassler (00:17:22 - 00:17:31)

Habe ich dir schon einmal gesagt, dass das wahnsinnig verwirrend ist mit diesem Minus und Plus und was es dann bedeutet in der Zeit? Ja, das ist ziemlicher Brainfuck.

Andy Grunwald (00:17:31 - 00:17:36)

Das ist ziemlicher Brainfuck. Deswegen, negative Schaltsekunden ist ein theoretisches Konstrukt.

Wolfi Gassler (00:17:36 - 00:17:42)

Also bei der negativen Schaltsekunde überspringe ich eine. Das heißt, die Zeit läuft eigentlich schneller.

Andy Grunwald (00:17:43 - 00:17:49)

Genau. Aber wurde noch nie getestet. Wurde noch nie getestet, kam noch nie vor. Wir hatten bisher.

Wolfi Gassler (00:17:49 - 00:17:51)

Es war schon 2020 einmal, ne?

Andy Grunwald (00:17:51 - 00:17:53)

Ne, 2020 hat sich nur die Erde einmal ein bisschen schneller gedreht.

Wolfi Gassler (00:17:53 - 00:17:56)

Es war nur ein Ausreißer.

Andy Grunwald (00:17:56 - 00:18:00)

Ja, ich weiß nicht, was die Erde. Ein bisschen Speed genommen oder so, keine Ahnung.

Wolfi Gassler (00:18:00 - 00:18:01)

Irgendwelche Schmetterlinge anscheinend.

Andy Grunwald (00:18:01 - 00:18:28)

In 21 hat die sich wieder ein bisschen langsamer gedreht. Aber wie dem auch sei, ich meine, im Endeffekt, zweitausendein, das kommt jetzt auch nicht jährlich vor. Bisher 27 mal seit 1902 und siebzigste, die letzte Schaltsekunde hatten wir 2016. Und ja, das Riesenproblem ist jetzt eigentlich die positive Schaltsekunde. Ich meine, da haben wir ein paar mal schon mitgemacht. 27 mal. Aber die negative Schaltsekunde, ich bin mal gespannt, ob die jemals eintreten wird. Forscher sagen, es kann sein, aber den Impact auf IT Systeme, der wurde noch nie getestet.

Wolfi Gassler (00:18:28 - 00:18:41)

Okay, dann bleiben wir mal bei dem Plus Beispiel, bei der normalen Schaltsekunde. Welchen Einfluss gibt es auf die IT? Weil eigentlich ist es ja nur okay, da ist 1 S irgendwo, die läppische S.

Andy Grunwald (00:18:41 - 00:19:11)

Das. Das ist jetzt faszinierend. Ich habe mal ein bisschen recherchiert und du findest immer mal wieder so ein paar kleinere Sachen, die sind weniger erforscht und dann findest du Sachen, die sind wirklich erforscht. Also im Jan. 2009, wir hatten 2008 eine Schaltsekunde am ein und dreiigster Dez. 2008 hat man eine Schaltsekunde, da gab es dann ein paar Linux Kernel Panics. Auch 2015 gab es so ein paar Situationen, da hat z.B. so ein Android Handy einfach zu früh Erinnerung von einem Kalender angezeigt. Finde ich jetzt eher mäßig schlimm.

Wolfi Gassler (00:19:11 - 00:19:12)

1 s zu früh?

Andy Grunwald (00:19:13 - 00:19:17)

Ne, ne, ne, wohl irgendwie schon einen Tag vorher oder ähnliches.

Wolfi Gassler (00:19:17 - 00:19:18)

Ah, ist irgendwas durcheinander gekommen?

Andy Grunwald (00:19:18 - 00:19:36)

Ja, ja, ganz genau. Und das war bei Twitter ebenfalls. Also die falsche Zeitberechnung. Wann wurde der Tweet gesendet? Da stand dann irgendwie ein paar Jahre anstatt paar Sekunden. Da hat anscheinend jemand in der Leap second einen Tweet gesendet. So was kam mal vor. Aber was so ein bisschen mehr erforscht ist, ist folgendes und zwar 2000 zwölfte.

Wolfi Gassler (00:19:36 - 00:19:45)

Aber jetzt noch die Frage, wenn es dann so verrückt spielt, gibt mir da die Zeitlibrary dann wirklich 60 zurück als Sekundenanzahl?

Andy Grunwald (00:19:45 - 00:19:49)

Ja, da musste er mir jetzt auch die Library sagen und die Sprache, weil.

Wolfi Gassler (00:19:49 - 00:20:19)

Sonst kann das ja eigentlich gar keinen großen Ÿousand einfluss haben, weil dann Speicher ist halt irgendwie, dann ist die Zeit falsch. Aber wenn es dann wirklich solchen Einfluss hat, dass dann ganze Tage fehlen oder irgendwas, dann muss ja schon irgendwie. Klingt schon eher danach, dass da irgendwie dann komischer Zeitwert zurückgekommen ist und dann ist alles irgendwie explodiert mehr oder weniger. Aber das lassen wir. Left to the audience als kleine Homework. Schreibt uns gerne im Discord, wenn wenn jemand versteht, wie das genau zustande gekommen ist oder sich da noch mehr reinladen will als Andi.

Andy Grunwald (00:20:19 - 00:20:49)

Also es gibt eigentlich zwei Fälle, die etwas mehr erforscht sind. 2012 ist einer, da war gefühlt das HW Internet down, also Reddit Meetup, LinkedIn, Yelp, Mozilla fast Mail, Opera. Da war sogar NTP Server abgeschmiert. Also NTP, für die Leute, die es noch nicht gehört haben, ist das Network Time Protocol. Das ist eigentlich dafür zuständig, um sich um die Uhrzeit zu kümmern. Und NTP Server sind auch zwei 12 auf Basis der Leap Second halt einmal hochgekachelt.

Wolfi Gassler (00:20:49 - 00:21:03)

Und NTP Server ist immer dieser Dienst, der nicht gestartet ist. Wenn man sich auf den Server einloggt und eine ganz krumme Zeit hat, dann muss man diesen Dienst wieder starten, der synchronisiert die Zeit und dann ist dein System wieder up to date. Im wahrsten Sinne des Wortes up to date.

Andy Grunwald (00:21:04 - 00:21:14)

Bei der Leapseck in 2012 kam es sogar dazu, dass im Hetzener Data Center die Power Consumption um 16 % von jetzt auf gleich anstieg. Ÿousand auf über einen MW.

Wolfi Gassler (00:21:14 - 00:21:15)

Warum denn das?

Andy Grunwald (00:21:15 - 00:21:19)

Ja, der Grund ist Linux. Und zwar folgendes.

Wolfi Gassler (00:21:19 - 00:21:22)

In Linux, nein, nur weil Mac nirgends.

Andy Grunwald (00:21:23 - 00:22:20)

Im Datacenter läuft, nein, die Erklärung ist relativ simpel, aber da hat die Linux Kernel Developer auch ein bisschen Zeit gekostet. Und zwar gibt es eine Komponente, die nennt sich HR Timer, High Resolution Timer oder High Rest Timer. Und zwar ist das ein Subsystem, das verwendet wird, wenn eine Anwendung schläft zweitausendein und darauf wartet, dass das Betriebssystem eine andere Aufgabe ausführt. Du kennst das so, es läuft ja oft nicht parallel, sondern es wird so getan, als läuft ein Prozess mehrere parallel. Der Scheduler, der pausiert deinen laufenden Prozess, macht für ein paar Millisekunden eine andere Berechnung und kommt dann wieder zu deinem Prozess. In einigen Fällen wird für diese schlafende Anwendung aber so eine Art Wecker gestellt. Und dieser Wecker, der schlägt halt an, wenn das Betriebssystem zu viel Zeit mit einer anderen Arbeit verbringt. Und immer wenn du einen Wecker gestellt hast, musst du natürlich kontinuierlich checken, aha, bin ich beim Wecker, ist mein Wecker abgelaufen und so weiter. Als die Schaltsekunde dann eingetreten ist, waren diese ganzen Wecker auf einmal 1 s voraus, weil du hast 1 s hinzugefügt.

Wolfi Gassler (00:22:20 - 00:22:24)

Also die Zeit war voraus, die Wecker waren abgelaufen dadurch alle, oder?

Andy Grunwald (00:22:24 - 00:22:45)

Ganz genau. Und auf einmal fingen alle Wecker an zu klingeln. Alle gleichzeitig. Sollte in der Regel nicht passieren. Das hat dazu geführt, dass alle schlafenden Anwendungen auf einmal geweckt wurden und die CPU von dem Server überlastet war. Wir reden aber, Achtung, von einem Linux Kernel. Wir reden hier nicht von einem Server, wir reden hier von ganz vielen Servern, nämlich bei Reddit, Meetup, LinkedIn, bei Opera und so weiter.

Wolfi Gassler (00:22:45 - 00:22:56)

Bei Hetzner, was sehr interessant wäre, ob da die Strom Consumption irgendwie dann weltweit nach oben gegangen ist, ob man, ob man das irgendwie sehen konnte.

Andy Grunwald (00:22:56 - 00:23:20)

Also bei Hetzner gingen die um 16 % nach oben. Da kannst du es sehen. Ich habe dir einen Link mit Graf angehangen. In den Shownotes, da könnt ihr es mal sehen von anderen Datacentern, die haben die Graphen nicht rausgegeben, aber die Antwort ist ja, die Power Consumption ging einfach mal nach oben. 2016 war was interessantes, und zwar ist der Cloudflare DNS Server abgekachelt. Cloudflare ist inzwischen eine riesen Company und wenn die Probleme haben, ist das halbe Internet down.

Wolfi Gassler (00:23:20 - 00:23:28)

Da läuft mein Lieblings DNS Server 1111. Früher hat man immer Google verwendet, 8888, aber 1111 ist viel cooler.

Andy Grunwald (00:23:28 - 00:23:56)

Ich weiß leider nicht, ob das jetzt genau der DNS Server war, aber 2016, ich weiß auch nicht, wie groß die damals waren, aber Punkt ist, wenn die Probleme haben, zweitausendein haben alle Probleme, was da passiert ist, die haben die die Dauer eines DNS Requests gemessen. Also das bedeutet, die haben den Zeitstempel genommen, haben dann einen Request gemacht und haben dann einen zweiten Zeitstempel genommen. Und in der Regel haben die dann die Endzeit minus der Startzeit gerechnet und haben angenommen, da kommt immer ein positives Ergebnis raus.

Wolfi Gassler (00:23:57 - 00:23:57)

Oder null.

Andy Grunwald (00:23:57 - 00:24:30)

Oder null, ganz genau. Und das ist leider eine falsche Annahme, besonders bei der Zweitausendein. Denn wenn diese Requests jetzt nicht Sekunden dauern, sondern wenige Millisekunden, was bei Cloudflare üblicherweise der Fall ist, dann, und du machst diese Berechnung genau während der Leap second, dann kann das Ergebnis negativ werden. Und da das in Go programmiert war, ist es damals mit einer sogenannten Panic, das ist ein fatal error in PHP oder eine nicht gecatchte Exception in Java, mit zu vergleichen, ist dann einmal mal der DNS Server hops gegangen.

Wolfi Gassler (00:24:31 - 00:24:42)

Moment, du hast es jetzt so als Go Fanboy sehr schnell übersprungen, dass das Go war. Und wenn ich mal diesen Blogpost so durchlese, da steht nämlich, dass Go keine Monotonic Clock anbietet.

Andy Grunwald (00:24:43 - 00:24:54)

Ja, 2000 Sechzehnte. Ja, also Monotonic Clock gibt es inzwischen, aber Wolfgang, was ist denn eine monotonic clock? Weil das wäre nämlich dann auch die Lösung. Aber wir können jetzt gleich auch mal mein Wissen abprüfen.

Wolfi Gassler (00:24:54 - 00:24:54)

Meinst du?

Andy Grunwald (00:24:54 - 00:24:56)

Wir können auch mal dein Wissen abprüfen.

Wolfi Gassler (00:24:56 - 00:25:30)

Aber ich passe ja immer gut auf. Du hast mir das in einer Episode schon mal erklärt, zweitausendein, ich kann mich nicht mehr erinnern, in welcher das war, aber du hast mir das natürlich erklärt, darum weiß ich das natürlich mittlerweile, dass man einfach eine monotonic clock, meistens eine andere Funktion aufrufen kann und da bekommt man dann keine klassische Zeit zurück, die gekoppelt ist mit wirklich mit der Zeit, sondern mit einfach einer tickenden Glock auf der CPU, die einfach immer weiter tickt und du bekommst einfach die Anzahl der Ticks eigentlich zurück und damit hast du da null Probleme mit irgendeiner Schaltsekunde. Aber das ist eigentlich nicht gekoppelt an irgendeine Datumsfunktion in dem Sinn.

Andy Grunwald (00:25:31 - 00:26:24)

Sehr gut. Ja, also wenn man von Monotonic Clock spricht, muss man eigentlich mal ganz kurz zurückgehen und zwar, dass wir einfach zwei Uhren im Computer haben und zwar einmal die Realtime Clock, das ist also mehr oder weniger den Unix Timestamp, Anzahl der Sekunden von 01.01.1970. Unix Timestamp soll so ein bisschen die Realzeit abbilden und der wird unter anderem durch NTP synchronisiert. Und weil das durch NTP synchronisiert wird, Achtung, kann das nach vorwärts oder rückwärts springen und sollte natürlich nicht zur Messung von irgendeiner Dauer, z.B. timeouts genutzt werden, wie z.B. cloudflare das gemacht hat. Und Monotonic Clock ist in der Regel implementiert als Counter oder beziehungsweise als Zähler, kann halt nicht springen wie z.B. nTP und ist deutlich besser zur Zeitmessung geeignet, wie z.b. wenn du mal auf einem Linux System uptime eingibst. Das ist eine monotonic Clock. In der Hinsicht gibt es sogar ein.

Wolfi Gassler (00:26:24 - 00:26:30)

PHP, habe ich gerade nachgeschaut, nennt sich HR Time, ist die höchste Auflösung und ist monotonic.

Andy Grunwald (00:26:30 - 00:26:32)

In der Regel gibt es das in jeder Programmiersprache.

Wolfi Gassler (00:26:32 - 00:26:38)

Ja, ja, aber PHP ist immer eine Ausnahme. Und aber es gibt sogar in JavaScript, glaube ich, du hast mir das damals.

Andy Grunwald (00:26:38 - 00:27:18)

Gezeigt, in JavaScript nach der letzten Leapsäcke, die 2016 war, wo Cloudflare auch abweggekachelt ist, hat Linux torwarts was schönes gesagt. Also eigentlich finden wir immer, wenn wir eine leap second haben, finden wir immer irgendeinen Bug. Und das ist richtig nervig, sagt er, denn eigentlich ist das der wahre Test, weil das ist alles Quellcode, der eigentlich nie unter diesen Konditionen ausgeführt wird. Und eigentlich ist die Leap Second auch keine Normal Condition. Also jeder Code, der noch nie auf einer Leap Second gelaufen ist, kann man eigentlich gar nicht sagen, dass der gut läuft. Und deswegen ist es so gefährlich, dass es zweitausendeinundzwanzig im theoretischen Konstrukt diese negative Liebsecken gibt, obwohl es die noch nie gab.

Wolfi Gassler (00:27:18 - 00:27:45)

Vor allem kann man es halt auch schwer testen, oder? Also du musst halt dann wirklich in irgendeinem, irgendeiner Sandbox laufen, die das wirklich simulieren kann, dass du da eine andere Zeit hast und dann wirklich dir das einmal durch simuliert vom Betriebssystem. Her und keine Ahnung, wie einfach das eigentlich ist. Falls jemand da eine Lösung kennt, bitte gerne bei uns im Discord mal reinschreiben, würde mich wirklich interessieren. Aber Raketen sind noch keine abgestürzt, oder? Das wäre so der Klassiker eigentlich. Die lässt man nie zur Leapsack starten.

Andy Grunwald (00:27:46 - 00:27:49)

Elon Musk ist relativ irre in letzter Zeit. Ich habe Keine Ahnung.

Wolfi Gassler (00:27:49 - 00:27:51)

Ja gut, bei dem explodiert ja regelmäßig.

Andy Grunwald (00:27:51 - 00:27:57)

Was, aber bei den Jungs und Mädels würde ich sagen, die nutzen sehr gute Monotonie Clocks. Von daher.

Wolfi Gassler (00:27:57 - 00:28:44)

Ja, das hat man bei der NASA auch immer gedacht, oder? Und dann waren es die klassischen Kleinigkeiten oder irgendwelche Umrechnungsfehler, die dann zum Absturz führen, sind halt immer diese Kleinigkeiten, die man, wo man dann selber auch sagt, ja, das kann mir eigentlich eh nicht passieren. Ich bin irgendwie high level, brauche das nirgends und dann geht dir halt dein DNS flöten. Also das würde ja auch niemand denken, dass es da Zusammenhänge gibt oder dass deine logging Library dann verrückt spielt oder so und irgendwie alles zerlegt. Also es ist ja wirklich schwierig, da die Auswirkungen auch wirklich einzugrenzen. Und darum ist es glaube ich, auch wichtig, dass man zweitausendeinousand so eine Information kennt, zumindest, dass man die im Hinterkopf hat und sie einfach mitdenken kann, dass es da unter Umständen Probleme geben kann. Vor allem, wenn man halt dann wirklich mit der Zeit arbeitet im Code.

Andy Grunwald (00:28:44 - 00:30:44)

Apropos Information kennt, damit wir auch alle wissen, wann die nächste Leap second kommt, findet existiert natürlich eine Implementierung im NTP Server statt. Network Time Protocol für die Leute, die sich wenig damit auskennen. Das ist eigentlich, wie der Wolfgang schon sagte, der Dienst auf eigentlich Linux System, Windows System und Co. Der für Zeit Synchronisation zuständig ist. Und er hat auch, also dieser Dienst oder das Protokoll hat auch eine Art und Weise, um mit Leap Seconds umzugehen. Und zwar werden Leap Seconds immer angekündigt, echt eine ganze Weile vorher, glaube ich vier Monate. Also ich glaube sechs Monate werden die offiziell angekündigt und dann in die Protokolle überführt. Und jetzt ist die Frage wie kriegt denn das NTP Protokoll mit, dass es bald ein Leapshecken gibt oder beziehungsweise wie wird die Informationen eigentlich zweitausendein durch die ganzen Computer gepackt? Da gibt es eigentlich zwei Arten. Und zwar könnt ihr euch vorstellen, dass NTP ähnlich wie DNS in so einer Baumhierarchie aufgebaut ist. Es gibt Downstratum Server, nennt sich das. Stratum null z.B. ist die höchste akkurate Referenzuhr. Das wäre dann z.b. so eine Atomuhr. Stratum eins holt sich die Zeit direkt von Stratum null, Stratum zwei holt sich die Zeit direkt von Stratum eins und so weiter. Ÿousand und Downstratum Server bedeutet halt, du gehst halt den Baum nach oben hoch zur Wurzel und die, wenn die eine neue Leapsecond haben und der NTP Server läuft, dann werden ein paar spezielle Bit gesetzt und die werden dann durch den Baum versendet, wenn man so möchte. Die zweite Geschichte und das ist die präferierte Methode. Es gibt ein sogenanntes Leap File, das kann sich jeder herunterladen, das haben wir auch in den Shownotes verlinkt. In dem leap File wird genau angezeigt, wann, wie, wo eine leap second eingeführt wird und was zweitausendein die, wie viel das ist und wie viel Sekunden wir dann jetzt hier springen. Und die wird beim Start des NTP Servers eingelesen und dann ist alles gut. Ich bin jetzt kein NTP Implementierungsspezialist, aber kurzum, dieses Protokoll kennt die Leap Second und kann damit rumgehen.

Wolfi Gassler (00:30:44 - 00:30:53)

Jetzt ist natürlich immer gut, so was im Hinterkopf zu haben, dieses Wissen. Aber gibt es Bereiche, wo mir das wirklich Probleme macht als klassischer Softwareentwickler?

Andy Grunwald (00:30:54 - 00:31:25)

Eins der Kernprobleme ist natürlich, dass ordnen von Events, also Event Ordering. Welches Event kam zuerst und wo findet das in der Regel statt? In fast allen verteilten Systemen, wo du einfach Events hin und her schickst. Ja, Synchronisierungsevents, Datenbank Synchronisierung, MySQL, Postgres. Und wenn du dir halt so richtige große Kaliber ansiehst wie Google Spanner, das sind halt hochkonsistente, weltweit verteilte Datenbanken oder global verteilte Datenbanken und da ist Ordering of Events First class citizen. Und wenn da die Zeit nicht stimmt, dann hat man richtige Probleme.

Wolfi Gassler (00:31:25 - 00:31:48)

Wenn ich das richtig noch im Kopf habe vom spanner Paper, es ist doch schon eine Zeit her, dass ich das gelesen habe. Aber die hatten, wenn ihr das richtig im Kopf habe, wirklich hardware Atomuhr Empfänger zumindestens an jeden Node gebaut, weil NTP oder andere Protokolle zu ungenau waren für ihren Zweck und die wirklich über eine Atomuhr synchronisiert haben.

Andy Grunwald (00:31:48 - 00:32:16)

Ja, genau. Das ist einer der Punkte, da musste ich mich dann bei der Recherche dieser Episode stoppen. Also wie funktioniert das bei Spanner? Spanner selbst hat eine sogenannte True Time Library eingeführt und die True Time Library basiert auf den eigentlichen Zeitservern in googles Data Center, die hardwarebasiert sind. Und diese zeitsynchronisierte Hardware oder die Hardware, die dafür sorgt und die Zeit synchronisiert, hat eine maximale Diskrepanz von sieben Millisekunden.

Wolfi Gassler (00:32:16 - 00:32:18)

Der ist gar nicht so wenig eigentlich. Sieben Millisekunden.

Andy Grunwald (00:32:19 - 00:32:24)

Gut, ob jetzt sieben Millisekunden viel oder wenig sind. Sorry, da bin ich jetzt raus. Also ich habe mir die.

Wolfi Gassler (00:32:24 - 00:32:45)

Naja, wenn du jetzt wirklich da feststellen willst, wer hat zuerst geschrieben, wenn du den gleichen Datensatz veränderst, ist durch sieben Millisekunden schon noch ordentlicher Brocken, würde ich mal sagen. Aber ich sehe schon, wir machen da eine eigene Episode dazu und laden uns mal Leute ein, die wirklich Ahnung haben, wenn es um solche Hardcore Probleme geht. Andi schreibt es mal auf die Liste.

Andy Grunwald (00:32:45 - 00:32:55)

Jetzt ist es natürlich so, jetzt haben wir die ganzen Probleme, welche Lösung gibt es? Und jetzt die beste Lösung, die glaubt mir jetzt keiner, server Reboot hilft immer. Die liebsten.

Wolfi Gassler (00:32:55 - 00:32:59)

Du kannst ja nicht den ganzen spanner Cluster mal durchtreten, einfach wenn du ein Problem.

Andy Grunwald (00:32:59 - 00:33:26)

Es geht ja nicht nur um Spanner, nicht jeder macht ja einen Spanner, es geht ja einfach nur um dein Kafka, um deine MySQL Replikation. Von mir ist auch um dein Linux Cluster, der seine HR Timer, seine Wecker alle aufwachen lässt. Also es ist ja nicht immer ein verteiltes System, es ist ja auch dein einzelner Server. Und bei den nächsten Leap Second kann es natürlich ebenfalls sein, dass genau sowas wieder im Kernel drin ist, weil wie Linux Torwart sagt, dieser Code läuft halt fast nie.

Wolfi Gassler (00:33:26 - 00:33:39)

Das heißt eigentlich das Beste wäre ja, wenn du den Computer einfach 5 s schlafen legst und dann wieder aufwachen lässt, dann ist alles in Ordnung. Dann hast du da keine Probleme zwischendrin gehabt. Oder 3 S anhalten.

Andy Grunwald (00:33:39 - 00:34:14)

Genau. Also ein server Reboot hilft immer, ist leider nicht immer das Beste. Deswegen habe ich mir mal angeschaut, was gibt es eigentlich für Lösungen auf dem Markt oder was machen denn Leute? Und zwar die einfachste, wir ignorieren die Schaltsekunde einfach. Und wer macht das? Das GPS System. Schöne NR. Also das GPS System wurde 1980 eingeführt und hat keine Schaltsekundenberücksichtigung. Und weil das 1980 eingeführt wurde, hat es mittlerweile eine Differenz zur UTC, zur koordinierten Weltzeit von 18 s.

Wolfi Gassler (00:34:14 - 00:34:34)

Jetzt wird ja GPS ganz oft verwendet als Zeitquelle, um irgendwelche Uhren zu stellen, Handy oder sonst irgendwas. Also Handy ist Handynetz, aber andere laufen ja durchaus über GPS. Haben die dann die Info wahrscheinlich gespeichert, dass das 18 S irgendwie falsch ist, checken das dann intern und passen das an.

Andy Grunwald (00:34:34 - 00:35:28)

Genau, die Differenz wird inzwischen mit dem GPS Signal mit übertragen, genau aus diesen Elementen, weil die sagen, oh ja, wir sind jetzt hier 18 s off. Jetzt fragt sich jeder, warum 18 s? 1972 bis 1980 waren ein paar Schaltsekunden und 18 s ist genau die Differenz, die wir jetzt gerade vom GPS System haben. Fun Fact, das russische GPS System GLONASS heißt das, die supporten Schaltsekunden. Aber wir reden jetzt die ganze Zeit von den GPS Systemen, die das ignorieren. Aber hey, Windows ignoriert es auch. Das war der Fun Fact schlechthin. Also und Windows macht es eigentlich super klug, muss ich zugeben. Ich habe ja gerade gesagt, der NTP Server, der Zeitsynchronisierung Server, der announced irgendwann Achtung, da kommt jetzt bald irgendwann eine Leap second. Also jetzt nicht nächste h, sondern der gibt dann schon den genauen Zeitpunkt mit wann die Leapsacken kommt. Windows ignoriert diese Anweisung, Windows sagt Leapseckend kenne ich nicht, ist mir egal.

Wolfi Gassler (00:35:28 - 00:35:32)

Und beim nächsten Sync wird einfach diese S dann angepasst.

Andy Grunwald (00:35:32 - 00:35:56)

Genau, die nehmen sich einfach die nächsten Zeit, synchronisieren nach der leap second und überschreiben einfach hart die Zeit. Das bedeutet für diese weiß ich nicht wann in welchem Intervall jetzt die Zeit Synchronisierung stattfindet, sind die dann 1 s off. Finde ich aber in irgendeiner Art und Weise keinen genauen, aber einen smarten Move. Ich habe jetzt auch noch nicht von wirklich vielen Problemen mit den Liebshacken bei Windows gehört, muss ich zugeben.

Wolfi Gassler (00:35:56 - 00:36:37)

Aber wenn ich mir das so überlege und NTP überschreibt ja auch oft die Zeit. Eigentlich hast du ja dieses dieses Problem, dass sich die Zeit ändert, ziemlich oft, weil wenn ich mir überlege, wie viel Server ich schon hatte, wo NTP nicht aktiviert war und die waren wirklich so um 20 Minuten oder so off mit der Zeit. Keine Ahnung wie das passiert, aber eigentlich hast du ja das wahrscheinlich relativ oft, dass die Zeit einfach geändert wird durch einen NTP update Call Synchronisation. Und eigentlich sollte deine Software schon damit umgehen können, weil das ja wirklich oft passieren kann. Also gerade ich kann mir vorstellen, bei Datenbanken ist das durchaus ein Problem, dass du einfach Einträge hast, die in der Zukunft liegen oder so, weil deine Zeit einfach upgedatet wurde oder umgekehrt.

Andy Grunwald (00:36:37 - 00:37:02)

Also viele Programmierer und Programmiererinnen denken, Zeit kann nur nach vorne gehen. Nein, wegen NTP kann die Zeit springen und sie kann auch rückwärts gehen und sie kann auch nach vorne springen. Zeitsynchronisation und Co. Also die Zeit geht nicht immer nur nach vorne. Bitte beachtet dies, wenn ihr Zeitberechnung durchführt. Ÿousand auf Basis der Realtime Clock natürlich nicht auf Basis der Monotonic Clock, hat mir gerade erklärt, was das ist. Aber Zeit kann springen und ist natürlich.

Wolfi Gassler (00:37:02 - 00:37:26)

Gerade gefährlich bei allen Synchronisations Algorithmen, wenn du mehrere schreibende Zugriffe auf dasselbe Datum hast, also nicht Datum im Sinne von von Kalender, sondern auf eine Zeile, einen Wert und du dann im Nachhinein irgendwie über die Zeitstempel das auflöst, kann es natürlich sein, dass du womöglich wirklich einen kompletten Bullshit berechnet hast, weil du in der Zwischenzeit einfach gesprungen bist in der Zeit zweitausendein. Da muss man schon extrem aufpassen.

Andy Grunwald (00:37:26 - 00:37:55)

Bei der Recherche zur Lösung einer Leap bin ich auch auf eine coole Sache gestoßen. Ich weiß nicht genau, wer das geschrieben hat, habe ich jetzt auch gar nicht wirklich gefunden. Aber es wird vorgeschlagen, dass man die Leap Second einfach liegen lässt, einfach ignoriert, einfach nicht nachzieht und dann im Jahr 2600 einfach eine ganze Liebstunde einführt, weil dann könnte man auf die häufigen, kleinen, unregelmäßigen Abständen zweitausendein auf die Anpassung verzichten und macht einmal einfach mal eine Liebstunde.

Wolfi Gassler (00:37:55 - 00:37:59)

Ja, du müsstest dann allen Leuten erklären, warum du da jetzt eine Zeitverschiebung hast.

Andy Grunwald (00:37:59 - 00:38:01)

Du meinst wie die Sommer und Winterzeit?

Wolfi Gassler (00:38:01 - 00:38:18)

Genau. Du könntest natürlich genau zu dem Zeitpunkt dann die Sommer und Winterzeit abschaffen und trotzdem noch einmal durchführen und dann hast du das mit einer Klappe erschlagen. Warum fragen sie nicht mich? Warum von dem International Büro auf irgendwas? Ich habe alle Lösungen.

Andy Grunwald (00:38:18 - 00:38:30)

Das ist in 570, 75 Jahren. Also ich bin mir nicht sicher, ob wir da noch viel zu sagen haben. Was ich mir halt die Frage gestellt habe, uh, schwierig. Ich meine, mit Sommer und Winterzeit sind wir jetzt klargekommen alle.

Wolfi Gassler (00:38:30 - 00:38:31)

Die wird ja abgeschafft.

Andy Grunwald (00:38:32 - 00:38:44)

Ja, da kommen wir gleich noch zu. Aber wenn du in 500 Jahren, also du hast seit 500 Jahren keine Liebsecken mehr. Wie viel Quellcode wird da erzeugt? Und dann hast du so einen Big Bang von einer Liebstunde.

Wolfi Gassler (00:38:44 - 00:38:45)

White. Okay, lässt grüßen.

Andy Grunwald (00:38:45 - 00:41:10)

Als weitere Lösung ist natürlich die Monotonic Clock da, wo man sie natürlich verwenden kann, wo ihr keine Real Clock oder Realtime Clock nutzen müsst. Immer wenn ihr z.B. die Dauer von einem Request messt, bitte nicht die Unix Time nehmen, da kriegt er nur Probleme. Nehmt einfach die Monotonic Clock oder nehmt halt auch an, dass die Subtraktion dann auch negativ werden kann. Und jetzt kommt's, jetzt kommt wieder die nerdigste Lösung und ich habe mich da so reingefressen. Und zwar geht es um die Schmiersekunde. Es wäre nicht Google, wenn Google nicht gesagt hätte, pass mal auf, diese Schaltsekunde gefällt mir nicht. Und die haben eine Schmiersekunde erfunden, die sogenannte Smear Second. Was die machen ist, wenn eine Schaltsekunde angekündigt wird, wird die zusätzliche S da so über Zeit reingeschmiert. Wie passiert das? Die lassen für 24 Stunden ihre Zeitserver um 11,6 Mikrosekunden langsamer laufen. Wenn du 24 Stunden jede S 11,6 Mikrosekunden lang laufen lässt, hast du über 24 Stunden eine zusätzliche Atomsekunde eingefügt, ohne dass du Probleme mit der Leap Second selbst hast, weil du dann keinen Zeitsprung hast. Ist das nicht genial? Ja, ich war, ich war, ich war voll, also sorry, das ist wirklich meines Erachtens nach ein cooles Engineering Problem oder beziehungsweise eine coole Engineering Lösung für ein reales Problem, weil sonst bist du nämlich irgendwie offline. Und jetzt kommt's, es gibt den Public Google NTP Server, auf den könnt ihr euch subscriben und der supportet das alles. Das bedeutet, du kannst sie dann auch nach Hause holen. Und wenn Google das macht, dann kopieren das natürlich ganz viele. Und AWS nutzt nämlich genau das gleiche Google Verfahren. Meta macht auch eine Smear second, die machen die aber nicht über 24 Stunden, sondern über 17 Stunden. Zweitausendein sogar Bloomberg, die Zeitung, also ist glaube ich ein bisschen mehr als eine Zeitung inzwischen, macht ebenfalls eine lineare Smearsecond über 2000 s, aber nicht vor der Einführung der Leap Second, sondern nach der Leap Second. Und eine Firma namens Meinberg, die stellen unter anderem so Zeit Synchronisations Hardware her. Und ich glaube, ich könnte mir vorstellen, dass Google auch diese Hardware nutzt. Die machen z.B. einen COSI [SOS/EOS], basierten Smear Algorithmus mit einer einstellbaren Dauer. Das bedeutet, kannst du sagen, okay, schmier mal dir die ganze S über die Dauer von einer Stunde rein.

Wolfi Gassler (00:41:10 - 00:41:21)

Aber wie, wie funktioniert das, wenn es in der Software passiert? Weil die S wird ja im Betriebssystem dann schon angepasst, oder? Also es ist eine Ebene höher dann über dem Betriebssystem.

Andy Grunwald (00:41:22 - 00:41:25)

Das ist eine sehr gute Frage, da bin ich jetzt leider raus, weil du.

Wolfi Gassler (00:41:25 - 00:41:35)

Hast ja gemeint, das ist eine Library. Insofern, außer die Library beeinflusst wirklich die Clock von der Hardware. Das wäre natürlich dann eine Möglichkeit.

Andy Grunwald (00:41:35 - 00:41:53)

Aber ja, es kommt auch ganz darauf an, auf welcher Basis bzw. Welche Basiseinheit operiert wird. Also ich meine, so ein NTP Server wird unten drunter mit hoher Wahrscheinlichkeit jetzt nicht auf Sekundenbasis agieren, sondern auf Millisekunden oder Mikrosekunden als Einheit, als Recheneinheit. Und von da aus, ja, also es.

Wolfi Gassler (00:41:53 - 00:42:07)

Könnte quasi so wie der NTP Server, wenn das die Smear Library von Google einfach da jeweils die Glock leicht anpasst um ein paar Millisekunden, also so, dann würde es natürlich betriebssystem weit funktionieren.

Andy Grunwald (00:42:07 - 00:42:43)

So stelle ich mir das jetzt vor. Ich bin kein NTP server Entwickler, da müssen wir mal jemanden fragen. Aber meine Frage ist jetzt gerade, warum ist das nicht die Standardlösung? Und ich habe drei Antworten gefunden. Also zum einen, das ist nicht die Standardlösung, denn es gibt ein Problem. Wenn der NTP Server in der Zeit, in der der das Verschmieren anwendet, neu gestartet wird, ist der Effekt irgendwie so ein bisschen ungewiss. Also wir wissen nicht, welche Zeit der NTP Server dann gibt. Die alte Zeit, die neue Zeit. Das war kommt sehr wahrscheinlich auch auf den NTP Server und auf die Smear Second Implementierung an. Aber das ist halt so, okay, könnte.

Wolfi Gassler (00:42:43 - 00:42:47)

Ein Bug sein, wobei du dann ja einfach die Zeit überschreiben kannst bei einem Reboot.

Andy Grunwald (00:42:47 - 00:42:51)

Ja, aber die Clients haben ja dann den Schmiereffekt. Auch gut, aber wenig Zeit.

Wolfi Gassler (00:42:51 - 00:42:52)

Überschreibstausend.

Andy Grunwald (00:42:52 - 00:43:51)

Man müsste mal rumspielen. Wir sollten uns mal so einen Smear Server aufsetzen. Die Frage ist aber, warum ist das nicht der neue Standard? Also zum einen gibt es leider weltweit keine zentralisierte Methode zur Zeiterfassung in den digitalen Systemen. Also das bedeutet, viele Computer nutzen jetzt hier NTP und da gibt es Leute, die nutzen Radiofrequenzwellen, um Zeiten zu synchronisieren und so weiter und so fort. Deswegen ist das jetzt ist das Smieren, dass das Schmieren, Smieren ist auch geil, jetzt nicht die Lösung für dieses Liebsecken Problem, weil das halt jetzt nur für diese digitalen Systeme funktioniert bzw. Die Computer. Die andere Geschichte ist, diverse Firmen können sich einfach nicht auf die Möglichkeit zur Berechnung der Smear Second einigen. Wir hatten gerade gesagt, es gibt ein lineares MIR Verfahren, Metern nutzen, quadratisches MIR Verfahren, dann mein Berg nutzen, cosinus basiertes Smear Verfahren. Also und dann über welche Dauer? Über 24 Stunden, über 2000 s, über 17 Stunden. Also da sind die alle irgendwie nicht so wirklich ein.

Wolfi Gassler (00:43:51 - 00:44:04)

Vor allem, was du ja dann auch sicherstellen musst, dass alle Geräte gleich schmieren, weil wenn du jetzt irgendein Cluster hast oder so ein Datenbankcluster, dann müsste das Schmieren natürlich überall gleich vonstatten gehen, sonst hast du wieder diese Inkonsistenz.

Andy Grunwald (00:44:04 - 00:44:46)

Ja, es ist halt jede Firma hat ihren Standard und lass uns doch mal einen neuen Standard machen, der alle Standards feint. Wer sich die ganze Sache aber mal ansehen möchte und c mächtig ist, es gibt die uns Mir Library auf GitHub von Google, der kann sich das alles mal ansehen. Also dieses Meerseckend war einer der Gründe, warum ich mich in dieses Thema so reingenerdet habe. Und beim reinnerden habe ich mich dann auch gefragt, so jetzt war vor acht Jahren die letzte Smear second. Wie sieht es denn jetzt eigentlich mit der mit der Schalt S aus? Machen wir das jetzt noch mal? Weil irgendwie gab es jetzt seit acht Jahren keine. Und da habe ich folgendes gefunden. Auf der einen Seite sagt Meta aka Facebook im Jahr 2002 ja, liebe Industrie, sollen wir jetzt mal die Leap Second irgendwie abschaffen?

Wolfi Gassler (00:44:46 - 00:44:46)

Zweitausendein.

Andy Grunwald (00:44:46 - 00:46:02)

Ich finde die ein bisschen überflüssig, weil deren Gründe ist, dass die Zeitsynchronisation zwischen der astronomischen Zeit, wir erinnern uns, Anfang der Episode Erdrotation und so, und die koordinierte Weltzeit, da besteht die Frage, warum müssen diese Zeiten überhaupt noch synchron sein? Denn die astronomische Zeit wird in der Regel nur noch von Astronomen verwendet und von ein paar Wissenschaftlern. Und viele Wissenschaftler nutzen heutzutage die koordinierte Weltzeit, also UTC. Also haben wir jetzt eigentlich zweitausendein, das schlechte aus beiden Welten. Für digitale Applikationen haben wir, haben wir UTC, die mit der Leapsackend irgendwie hantieren muss. Und die ganzen Astronomen, die nutzen eh die astronomische Zeit oder die Atomzeit. Also kaum einer nutzt irgendwie beide Zeiten gleichzeitig. Also warum müssen die in Sync sein? Das ist die große Frage. Und Google, Microsoft, Amazon und Co. Sagen eigentlich, eigentlich habt ihr recht, brauchen wir alles irgendwie nicht mehr. Meta schlägt jetzt keine wirkliche Lösung vor, sondern die sagen nur, sollen wir jetzt nicht einfach mal die Schaltsekunde abschaffen? Und dann habe ich ein bisschen weiter recherchiert und gefunden, dass die ganze Thematik schon länger diskutiert wird. Es wurde aktuell entschieden, bei Achtung, der Generalkonferenz für Maß und Gewicht. Kennst du die? Es gibt für alles eine Generalkonferenz und ein Institut.

Wolfi Gassler (00:46:02 - 00:46:05)

Finde ich grandios, muss eine deutsche Erfindung sein.

Andy Grunwald (00:46:05 - 00:46:52)

Die haben sich auf jeden Fall im November 22 zusammengesetzt und entschieden. Die haben dafür gewotet, hey Jungs und Mädels, ab 2005 und dreiig lassen wir das mit der Schaltsekunde sein. Jetzt denkst du natürlich, das ist jetzt schon entschieden. Nee, das muss von der internationalen Fernmeldeunion 2026 noch mal bestätigt werden. Und dann könnte es sein, dass wir ab 2005 und Dreiig keine Schaltsekunde mehr haben. Aber Achtung, jetzt kommt der Fun Fact. Die haben nicht beschlossen, ab 2,35 schmeißen wir die Schaltsekunde weg. Was die sagen ist, wir lassen zwischen dem Jahr 2005 und dreiig und 2105 und dreiig die astronomische Zeit und die koordinierte Weltzeit auseinanderdriften, in der Hoffnung, dass Wissenschaftler eine bessere Methode entwickeln, um die verlorene Zeit auszugleichen.

Wolfi Gassler (00:46:52 - 00:46:57)

Ja, ist eigentlich eine intelligente Herangehensweise. Sollen sich doch die Leute in der Zukunft den Kopf drüber zerbrechen.

Andy Grunwald (00:46:57 - 00:47:10)

Für alle Software Engineers, ich möchte mal eins sagen, und im Site Reliability Engineering und bei diesen ganzen Systemadministratoren und Betrieb und DevOps und so gibt es eine Regel, Hoffnung ist keine Strategie.

Wolfi Gassler (00:47:10 - 00:47:15)

Ja, aber du sollst auch nicht Probleme lösen, die du jetzt nicht hast. Insofern, ja, ich finde es geil.

Andy Grunwald (00:47:15 - 00:47:31)

Also warten wir mal 2026 ab, was die internationale Fernmeldeunion denn so bestätigt. Ob wir einfach mal für 100 Jahre die Schaltsekunde aussetzen und dann in der Hoffnung, dass 2105 und dreiig Wissenschaftler Lösungen gefunden haben. Wahnsinn.

Wolfi Gassler (00:47:31 - 00:47:36)

Wie gesagt, wenn man die Regenwürmer einfach in die richtige Richtung treiben könnte, dann hat man das alles gelöst.

Andy Grunwald (00:47:36 - 00:47:51)

Also vielleicht hat man es in der Episode ein bisschen gehört. Ich hatte bei dieser Vorbereitung und bei diesem reinen Nerden so viel Spaß, so viel Zeit und der Umgang mit Zeit in der Softwareentwicklung. Ich habe nicht gedacht, dass es so ein Rabbit Hole ist und ich habe nur an der Oberfläche gekratzt.

Wolfi Gassler (00:47:51 - 00:47:53)

Es ist ja nur 1 S.

Andy Grunwald (00:47:53 - 00:49:45)

Ja, es ist nur 1 S. Wir hatten ein bisschen über die True Time Library bei Google Spanner gesprochen. Das würde mich auch mal interessieren. Wie funktioniert das? Wir hatten ein bisschen über Zeit Synchronisations Hardware gesprochen. Mega geil. Ich wusste gar nicht, dass es dafür Hardware gibt. Dann habe ich bin ich in meinen Artikel gestolpert, wie Facebook, also Meta sagt, wie die ihre NTP Server in ihren kompletten Datacentern aufsetzen. Den muss ich auch noch mal durchlesen. Und wenn ich mich da reingenördet habe, vielleicht machen wir dazu noch mal eine Episode. Und dann habe ich einen geilen Blogpost gefunden, der sagt einfach scheiße Zeit ist ungefähr wie das Kap Theorem, weil der sagt, du kannst nur zwei haben, entweder präzise Zeit und Einfachheit oder Einfachheit und valide Kalendertage oder präzise Zeit und valide Kalendertage, aber nicht Einfachheit. Also der nimmt all diese Thematik mit der Erdrotation und der Atomsekunde und so weiter, mit der Definition, die wir hier gerade besprochen haben, mal auseinander und vergleicht das so ein bisschen wie das Kap Theorem, das du eigentlich alles haben kannst. Denn die Kalendertage, also auch das Schaltjahr, richtet sich wieder nach der Erdrotation. Zweitausendein. Du merkst schon den Konflikt hier. Du kannst jetzt nicht sagen, du hast präzise Zeit anhand der Atomsekunde oder die Einfachheit, dass jeder Tag Sekunden hat oder dass du akkurate Kalender hast, die nach der Erdrotation gehen. Alles drei geht nicht. Und in meinem Kopf, kennt ihr dieses Emoji mit diesem, wo man das Gehirn sieht und dieses Exploding Head Emoji, heißt das so? Mein Kopf geht gerade so viel ab. Scheiße, ist das kompliziert, aber geil. Und ich finde das so unglaublich spannend zweitausendein, weil wir denken, wir haben damit wenig zu tun, aber wir lügen uns alle so in die Tasche, weil Zeitberechnung machen wir alle dauerhaft, täglich, auch wenn es die Dauer eines Requests ist, die wir berechnen wollen. Und wer da jetzt nach dieser Episode noch den Unix Time Step für nimmt, den haue ich.

Wolfi Gassler (00:49:45 - 00:49:49)

Wieso? Der ist ja trotzdem noch gut geeignet für vieles.

Andy Grunwald (00:49:49 - 00:49:58)

Da nutzt man eine Monotonic Glock, haben wir doch heute gelernt. Ich werde auf jeden Fall mindestens noch eine Episode zu diesem Zeitthema machen. Ich finde das einfach geil. Ich habe so viel Spaß dabei.

Wolfi Gassler (00:49:58 - 00:50:09)

Auf jeden Fall kann ich dich jetzt endlich akademisch nennen, wenn du so eine akademische Episode vorschlägst, vorbereitest und durchziehst. Alleine dafür war die Episode schon gut.

Andy Grunwald (00:50:09 - 00:50:16)

Mit Praxisbezug. Praxisbezug. Ich hoffe, ihr alle hattet auch so viel Zeit. Ich hoffe, ihr alle hattet auch so viel Spaß wie ich.

Wolfi Gassler (00:50:17 - 00:50:19)

Das war jetzt ein freudscher Versprecher, oder?

Andy Grunwald (00:50:20 - 00:50:21)

Ich glaube schon.

Wolfi Gassler (00:50:21 - 00:50:22)

Das alles nur für die s.

Andy Grunwald (00:50:22 - 00:50:32)

Es tut mir leid, falls es so ein bisschen verwirrend war. Man muss sich echt konzentrieren, wenn man über diese verschiedenen Zeiten, Erdrotation, mittlerer Sonnentag und Co. Spricht.

Wolfi Gassler (00:50:32 - 00:51:26)

Ja, dem kann ich nur beipflichten, weil wir hatten schon im Vorgespräch wirklich teilweise brainfuck mit minus s plus s, welche Zeit läuft wie rum. Also es ist wirklich schwierig, das zu verstehen. Was mein Punkt ist, den ich mir aber auch mitgenommen habe, ist, dass wir einfach, wenn wir mit Zeit operieren in unserer Software, einfach besser darauf achten müssen, dass wir nicht immer annehmen können, dass die Zeit nach vorne läuft. Und klar, S ist jetzt wirklich ein Edge Case und ich würde mal sagen, für die 99 oder 90 % aller Software ist es gar nicht so schlimm, diese S. Aber man hat halt auch andere Einflüsse. Die Zeit kann sich ändern, es kann was synchronisiert werden. Und mein Learning ist da einfach, dass man darauf mehr achten muss, weil ehrlich gesagt habe ich ganz selten an irgend so was gedacht, dass ich die Zeit mal ändern kann. Und da kann man dann schon einiges kaputt machen unter Umständen. Und das sind dann bugs, die wahnsinnig schwierig zu finden sind.

Andy Grunwald (00:51:26 - 00:51:31)

Ja, man hat nämlich nur 27 Retries seit 1902 und siebzigste.

Wolfi Gassler (00:51:31 - 00:51:41)

Ja, aber auch wenn sich die Zeit so ändert, das kann durchaus mal passieren. Und dann hast du ein großes Problem, wenn du wirklich Operationen auf der Reihen, auf der Zeit machst und durchführst.

Andy Grunwald (00:51:41 - 00:52:27)

Ja, ich glaube schon, dass du ein Test Setup hinkriegst, aber ich glaube, das ist halt schon relativ aufwendig dann, weil du ja, ich sag mal, wirklich einen Zeitserver faken muss oder vielleicht sogar einen Zeitserver aufsetzt und den springen lässt und so. Also ist schon sehr sehr aufwendig. Wer sich ein bisschen in das Thema rein nerden möchte, in den Show Notes findet ihr etliche Links zu diesem Thema, die ich z.B. zur Recherche genutzt habe und gefunden habe. Da findet ihr auch das Liebsecken Pfeil, da findet ihr die True Time API von Spanner, da findet ihr die Smear Algorithmen von Google, den Public NTP Server, wie AWS die Smear senden macht. Da gibt es die Entscheidungen, die Schaltsekunde auszusetzen und so weiter und so fort. Schaut einfach mal rein, vielleicht habt ihr auch ein bisschen spaß. Und ansonsten würde ich sagen, sehen wir uns in der Discord Community, sprechen mal ein bisschen über Zeit.

Wolfi Gassler (00:52:27 - 00:52:42)

Bis bald, tschüss, ciao, gute Zeit. Und nicht vergessen, wenn du Impact haben willst in einem kleinen Engineering Team und vielleicht auch noch remote Zweitausendein, schau vorbei bei unserem Episodensponsor Easybill. Link findest du in den Shownotes.