Verstrichene Zeit seit der Epoche

 (aphyr.com)
2 Punkte von GN⁺ 2024-12-27 | 1 Kommentare | Auf WhatsApp teilen
  • POSIX time/Unix time wird oft als Anzahl der Sekunden seit 1970-01-01 00:00:00 bezeichnet, ist tatsächlich aber ein UTC-basierter Wert, der Schaltsekunden ignoriert und daher von den tatsächlich verstrichenen Sekunden abweicht
  • Zum Zeitpunkt 2024-12-25 18:51:26 UTC beträgt die POSIX time 1735152686, während seit der Epoch tatsächlich 1735152713 Sekunden verstrichen sind – eine Differenz von 27 Sekunden
  • IEEE 1003.1 rechnet bei der Definition von seconds since the Epoch jeden Tag stets mit 86.400 Sekunden; auch der Anhang des Standards ignoriert die seit 1970 hinzugefügten 14 Schaltsekunden zugunsten von Kompatibilität und einfacher Berechnung
  • UTC fügt Schaltsekunden hinzu, um die Abweichung vom Sonnentag zu verringern; dabei springt die POSIX time zurück, was zu Ausfällen wie bei Linux, Qantas und Cloudflare DNS geführt hat
  • Für die Messung von Zeitintervallen auf einem einzelnen Computer sind CLOCK_MONOTONIC oder CLOCK_BOOTTIME besser; wenn Abgleich mit POSIX timestamps nötig ist, sollte man leap smear oder POSIX↔TAI-Konvertierung in Betracht ziehen

POSIX time ist nicht die tatsächlich verstrichene Sekundenzahl

  • JavaScript Date, GNU coreutils, Linux time(2), Go time.Unix, MySQL datetime, Ruby Time, Cassandra timestamp usw. behandeln POSIX time häufig wie die Sekunden seit der Unix epoch
  • Diese Formulierung entspricht jedoch nicht ganz der üblichen Intuition
    • Beispielzeitpunkt: 2024-12-25 18:51:26 UTC
    • POSIX time: 1735152686
    • Tatsächlich verstrichene Sekunden seit der POSIX epoch: 1735152713
    • Differenz: 27 Sekunden
  • Diese Differenz entsteht, weil POSIX time in IEEE 1003.1 zwar von UTC abgeleitet ist, aber für jeden Tag exakt 86.400 Sekunden annimmt
  • Die Definition von seconds since the Epoch im Standard berechnet den Wert anhand von tm_sec, tm_min, tm_hour, tm_yday und tm_year; die Beziehung zu Jahren vor 1970 oder zu negativen Werten ist nicht definiert
  • Die tatsächliche Länge eines Tages beträgt nicht immer 86.400 Sekunden und ändert sich über die Zeit
    • Damit UTC-Daten nicht zu weit vom Sonnentag abweichen, erklären Astronomen periodisch Schaltsekunden
    • Dadurch kann POSIX time alle paar Jahre rückwärts springen
    • Irgendwann könnte sie auch vorwärts springen
  • Schaltsekunden haben bereits zu realen Ausfällen geführt

Kompromisse im Standard und praktische Alternativen

  • Anhang B von IEEE 1003 hält fest, dass zum Zeitpunkt der Veröffentlichung des Standards seit 1970-01-01 14 Schaltsekunden hinzugefügt worden waren, diese 14 Sekunden aber zugunsten einfacher Berechnung und Kompatibilität ignoriert werden
  • Der Standard geht davon aus, dass der „time“-Wert der meisten Systeme kontinuierlich steigt, und entscheidet sich dafür, dass dieser Wert auch während einer Schaltsekunde steigen soll
    • Gleichzeitig setzt er voraus, dass die meisten Systeme Schaltsekunden nicht verfolgen oder möglicherweise nicht mit einer Standardzeitbasis synchronisiert sind
    • Daher verlangt er nicht, dass seconds since the Epoch zwingend die exakte Anzahl der Sekunden zwischen Referenzzeitpunkt und epoch darstellt
    • Es genügt, wenn Anwendungen diesen Wert wie Sekunden seit der epoch behandeln können; die erforderliche Genauigkeit sollen Systemanbieter und Administratoren sicherstellen
  • In verteilten Anwendungen kann eine konsistente Interpretation wichtig werden, weil Events über timestamps synchronisiert werden
    • Die Ansammlung von Schaltsekunden ist nicht vorhersagbar
    • Die Zahl der Schaltsekunden seit der epoch kann weiter steigen
    • Der Standard interessiert sich stärker für Zeitsynchronisierung zwischen Anwendungen über astronomisch kurze Zeiträume
  • Reale Systeme funktionieren meist auch bei leicht abweichender Zeit, doch Schaltsekunden sind selten, und die lineare Intuition von „Sekunden seit der epoch“ ist stark – dadurch können sich unentdeckte Bugs ansammeln
  • Je nach Situation bieten sich folgende Alternativen an
    • Wenn auf einem Computer nur die duration zwischen zwei Events berechnet werden soll: CLOCK_MONOTONIC, besser noch CLOCK_BOOTTIME, verwenden
    • Wenn keine timestamps mit anderen Systemen ausgetauscht werden müssen, die POSIX time voraussetzen: TAI, GPS, LORAN verwenden
    • Wenn eine grobe Abstimmung mit POSIX-timestamp-Systemen nötig ist: Schaltsekunden per leap smear über einen längeren Zeitraum verteilen
    • Mit Bibliotheken wie qntms t-a-i ist eine Konvertierung zwischen POSIX und TAI möglich
  • Es laufen Bemühungen zur Abschaffung von Schaltsekunden, deren Umsetzung bis 2035 erwartet wird
    • Für alles, was auf der Annahme ein Tag hat 86.400 Sekunden beruht, ist zusätzlicher Aufwand nötig, um Konvertierungstabellen einzubauen
    • Für Zeitpunkte nach 2035 könnten Fragen wie „Wie viele Sekunden liegen zwischen zwei Zeitpunkten?“ deutlich einfacher werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-27
Hacker-News-Kommentare

  • Ich habe gerade Vernor Vinges SF-Roman A Deepness in the Sky aus dem Jahr 2000 gelesen; ein großartiges Buch mit einer unerwarteten Erwähnung von Sekunden seit der Epoch (seconds since the epoch).
    Es beginnt mit „Betrachten Sie die Art, wie die Traders Zeit messen …“ und beschreibt, dass die Qeng Ho in Sekunden ab dem Moment zählen, in dem die Menschheit erstmals den Mond der Old Earth betrat; bei genauerem Hinsehen liegt der Startpunkt aber tatsächlich etwa 15 Millionen Sekunden später, beim Zeitpunkt null eines der frühen Computerbetriebssysteme der Menschheit.

    • Das Buch gehört für mich zu meinen absoluten Favoriten, und ich mag sehr, wie es subtile Software-Referenzen einsetzt.
      Wenn man mehr „Informatik im Weltraum“ möchte, empfehle ich die Bobiverse-Reihe; wenn man mehr Erkundung von „Mensch + Simulation + Computer“ möchte, Permutation City.

  • Jedes Mal, wenn ich über Zeitmessung lese, lerne ich unweigerlich etwas Neues. Ich hatte Unix-Zeit immer für die einfachste Art gehalten, Zeit zu verfolgen, wenn man nur Rollovers berücksichtigt, und Schaltsekunden kannte ich zwar, aber ich hatte nicht daran gedacht, dass sie auch hier gelten.
    Ich habe auch den Link „UTC, GPS, LORAN and TAI“ gelesen; der Kontrast, dass GPS-Zeit Schaltsekunden nicht berücksichtigt, ist interessant.

    • Zu sagen, dass etwas einige Sekunden vor/nach einem Zeitpunkt passiert ist, ist einfach. Schwierig ist es, diesem Zeitpunkt ein Kalenderdatum zuzuweisen.
    • Unterm Strich scheint mir TAI am einfachsten zu sein; andere Formate sollte man nur bei Bedarf aus TAI umrechnen, etwa für die Anzeige oder Interoperabilität.

  • Der Plan, „bis 2035 Schaltsekunden abzuschaffen“, gefällt mir nicht besonders.
    Der Kern von UTC ist, dass es um eine ganze Zahl von Sekunden von TAI abweicht und der mittleren Sonnenzeit (MST) nahekommt. Wenn man MST nicht mehr verfolgen will, sollte man einfach auf TAI umstellen.
    Lässt man UTC von MST wegdriften, muss man die historischen Schaltsekunden weiterhin behandeln, aber diese Schaltsekunden haben dann keinen Zweck mehr – ein halbgarer Zustand.

    • Ich stimme zu, dass das Abweichen von MST mehr kostet, als es bringt.
      Allerdings ist dieser Vorschlag nicht völlig sinnlos. Ziel ist, die bestehende UTC-Zeitverwaltung nicht zu ändern, sondern dafür zu sorgen, dass die Differenz zwischen zwei Zeitstempeln nach 2035 der exakten Anzahl physikalischer Sekunden entspricht.
      Trotzdem wirkt es lächerlich, MST zu entfernen, da es bereits eine Funktion von UTC ist.
    • In einer idealen Welt hätten Computersysteme TAI zur Zeiterfassung verwendet und mithilfe der TZ-Datenbank nach UTC oder in lokale Zeit umgerechnet.
      In der Realität haben jedoch viele Systeme die falsche Wahl getroffen, insbesondere UNIX ist der Hauptgrund. Diese Entscheidung ist so tief in unzähligen Systemen und Vorschriften verankert, dass ein „einfacher Wechsel zu TAI“ praktisch unmöglich ist.
      Deshalb ist es einfacher, UTC als „neues TAI“ neu zu interpretieren. Es würde mich nicht überraschen, wenn das frühere UTC irgendwann unter einem anderen Namen wieder auftaucht.
    • Es gibt keine separate Entität namens TAI. TAI erhält man, indem man von UTC ausgeht und die Anzahl der relevanten Schaltsekunden abzieht. TAI wird nicht als eigenständige Standardgröße gepflegt.
      In den meisten oder allen Ländern basiert die zivile Zeit auf UTC. Niemand wird die Uhren der ganzen Welt um etwa 30 Sekunden zurückstellen, nur weil das etwas reiner wäre.
      Auch die GPS-Zeit hat einen Offset zu TAI, aber niemand kümmert sich groß darum. Dasselbe gilt für die Unix-Epoch; solange die Ergebnisse konsistent sind, reicht das.
    • Der Hack ist buchstäblich trivial. Einmal im Monat prüfen, ob UTC # ET ist; falls nicht, eine Datei namens Leap_Second anlegen. Jeden Monat prüfen, ob diese Datei existiert; wenn ja, sie löschen, den Wert in der Datei Leap_Seconds um 1 erhöhen und ein Backup namens LSSE erstellen.
      „You are not expected to understand this.“ So hält man beide Systeme aufrecht. Wenn man will, kann man es auch mit Hashes oder Lookup-Tabellen bauen.

  • Wichtig ist auch, dass die moderne UTC-Epoch der 1. Januar 1972 ist. Davor verwendete UTC eine andere Sekundenlänge als TAI.
    Ende 1971 gab es als Zwischenschritt einen letzten unregelmäßigen Sprung von exakt 0,107758 TAI-Sekunden, und die kleinen Zeitschritte sowie Frequenzanpassungen von UTC oder TAI zwischen 1958 und 1971 wurden so abgestimmt, dass ihre Summe genau 10 Sekunden ergab. Daher war der 1. Januar 1972, 00:00:00 UTC, exakt der 1. Januar 1972, 00:00:10 TAI, und seitdem beträgt die Differenz eine ganze Zahl von Sekunden.
    Gleichzeitig wurde die Tickrate von UTC exakt gleich der von TAI, und UTC begann, UT1 statt UT2 zu verfolgen. Daher stimmt die Unix-Zeit der Jahre 1970 und 1971 nicht mit der tatsächlichen UTC-Zeit jener Zeit überein.
    https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His...
    https://en.wikipedia.org/wiki/Unix_time#UTC_basis

    • Deshalb gibt es unter den heute lebenden Menschen einige, die ihr exaktes Alter (in Sekunden) nicht kennen können und auch nie kennen werden.
      Selbst wenn man annimmt, dass die Uhrzeit in der Geburtsurkunde sekundengenau ist, gilt das. Denn während eines Teils ihres Lebens war der Wert, der als „Länge einer Sekunde“ galt, im Vergleich zu dem, was wir heute gewöhnlich unter einer Sekunde verstehen, ziemlich anders.
      Mit Sekunde ist hier die Sekunde gemeint, die auf der ungestörten Hyperfeinübergangsfrequenz des Grundzustands des Cäsium-133-Atoms von 9.192.631.770/s basiert.

  • Ich habe kürzlich Code für eine Börse geschrieben; das System lief auf VAX, genauer gesagt auf OpenVMS, und die Epoch war der 17. November 1858.
    Es war das erste Mal in meiner Laufbahn, dass ich eine nicht-Unix-Epoch gesehen habe; zum Glück war sie im verwendeten Code auf die Unix-Epoch abstrahiert.

    • Die Epoch von 1858 scheint vom astronomischen Standardkalender Julian Day zu stammen. Dort ist Tag 0 im Jahr 4713 v. Chr.
      https://www.slac.stanford.edu/~rkj/crazytime.txt
      Um diese Daten in den Computerspeicher der 1950er-Jahre passen zu lassen, wurde der Kalender um 2,4 Millionen Tage versetzt; dadurch wurde Tag 0 zum 17. November 1858.
    • Es gibt auch eine alte Microsoft-Anekdote über den Konflikt zwischen Excels Epoch, dem 1. Januar 1900, und Basics Epoch, dem 31. Dezember 1899.
      https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
    • Ein weiteres verbreitetes Computersystem, das man kennen sollte: Die Windows-Epoch ist der 1. Januar 1601.
    • Klassisches MacOS, Apples HFS-Dateisystem (auch unter OS X verwendet) und PalmOS hatten alle den 1. Januar 1904 als Epoch.
      Die macOS/Swift-Foundation-API NSDate.timeIntervalSinceReferenceDate verwendet den 1. Januar 2001 als Epoch.
      Wikipedia hat ebenfalls eine nützliche Liste: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
    • PostgreSQL verwendet intern eine 2000-01-01-Epoch zur Speicherung von Zeitstempeln.

  • Manche Zeitpunkte lassen sich nicht als POSIX-Zeitstempel darstellen, und manche POSIX-Zeitstempel entsprechen keiner realen Zeit.

    • Mich würde interessieren, welche POSIX-Zeitstempel keiner realen Zeit entsprechen. Oder geht es dabei um den Fall, dass es in Zukunft eine negative Schaltsekunde gibt?
    • Das war schon immer so. In Unix-Zeit ist vor 1970 nicht definiert.
    • Immerhin entspricht wenigstens nicht ein POSIX-Zeitstempel mehreren realen Zeitpunkten. Das ist besser als eine einzige Darstellungsform, die Leute für alles verwenden.
    • Doch.
      Das ist ungefähr so, als würde man sagen, es gebe Zeitpunkte ohne ISO-8601-Jahr. Jeder Zeitpunkt hat ein Jahr, nur sind manche Jahre länger als andere.
      Wenn man sich hinsetzt und https://time.is/UTC anschaut, wird die Zeit monoton steigen; gelegentlich ist nur eine Sekunde ein ganz kleines bisschen länger. Zum Beispiel über 24 Stunden hinweg etwa 0,001 % länger.

  • Wenn ich Datumsangaben in einer Datenbank speichere, speichere ich sie immer als Unix-Epoch-Zeit und hinterlege in Datumsfeldern keine Zeitzoneninformationen. Wenn es eine Anforderung gibt, die Zeitzone zu kennen, speichere ich sie separat.
    Ich frage mich, ob man stattdessen Zeitstempel im TAI-Format speichern und bei Bedarf Funktionen zur Umwandlung nach UTC verwenden sollte, damit erdbezogene Korrekturen bei Bedarf behandelt werden können.
    Mir ist klar, dass Zeitzonen ein Minenfeld sind, aber auch sie sind ein menschliches Konstrukt, dessen Grenzen sich im Lauf der Zeit ändern. Es scheint, als sollte man auf absolute Zeit fixieren und sie dann bei Bedarf im gewünschten lokalen Zeitformat rendern.

    • Stimmt. TAI oder ein ähnliches Format ist die einzig vernünftige Art, „System“-Zeit zu verfolgen, und höher liegende Systeme sollten sie in für Menschen sichtbare Zeit umwandeln.
      Schaltsekundenkorrekturen sollten an derselben Stelle stattfinden wie Zeitzonenumwandlungen. Leider hat Unix das Falsche standardisiert, und Migrationen sind schwierig.
    • Eher nicht, fast nie. Die meiste Software ist so geschrieben, dass sie Schaltsekunden überdeckt; in der Praxis treten sie nur in der Schicht zur Uhrensynchronisierung auf. chrony implementiert zum Beispiel Leap-Second-Smearing.
      Daher sind alle Uhren ohnehin auf UTC ausgerichtet. Beim Speichern müsste man von UTC nach TAI konvertieren und beim Lesen wieder zurück; das würde ein Durcheinander geben.
    • Zu „in Datumsfeldern keine Zeitzoneninformationen hinterlegen“: Tatsächlich gibt es nur sehr wenige Datenbanken, die bei Zeitstempelspalten eine Bewahrung der Zeitzone ermöglichen.
      Üblicherweise haben Datenbanken entweder kein Zeitzonenkonzept für gespeicherte Zeitstempel (SQL Server) oder sie bieten einen „zeitzonenbewussten“ Zeitstempeltyp, konvertieren die Eingabe aber nach UTC und verwerfen die ursprüngliche Zeitzone (MySQL, Postgres).
      Soweit ich weiß, kann nur Oracle bei with time zone-Typen eine nicht-lokale Zeitzone tatsächlich rundtripfähig bewahren.
    • Es hängt davon ab, was das System speichert. Den meisten Systemen ist es egal, wenn sie alle paar Jahre um 1 Sekunde danebenliegen.
      Bei manchen Berechnungen ist eine Abweichung von 1 Sekunde ein großes Problem. Wenn man etwas anderes als das am weitesten verbreitete Format übernimmt, sollte man vorsichtig sein und einen guten Grund haben, vom Standard abzuweichen. Schon die bloße Tatsache, anders zu sein, kann hohe Kosten verursachen.
    • Man kann einfach die nativen Datums-/Zeitfelder der Datenbank verwenden.

  • Durch diesen Artikel fühlt es sich an, als sei Weihnachten ruiniert. Ist denn nichts heilig? Sekunden sollten Sekunden seit der Epoch sein.
    Ich verstehe nicht, warum man sich darum kümmern sollte, dass das ein wenig vom Sonnentag abweicht. Sollte nicht der Konverter, der Sekunden seit der Epoch in eine Datumsdarstellung umwandelt, für die Korrektur verantwortlich sein?

    • Die aktuelle Methode ist tatsächlich die, die wir wollen. 86400 Sekunden = 1 Tag, und wir arbeiten unter der Annahme, dass Mitternacht UTC immer ein Vielfaches von 86400 ist.
      Wir wollen nicht, dass jede Software die Einführung von Schaltsekunden fest eincodiert, Smearing behandelt und innerhalb eines Monats eine Update-Methode benötigt, wenn eine neue Schaltsekunde eingeführt wird.
      Bisher mussten wir uns darum weder sorgen noch darüber nachdenken, und das müssen wir auch künftig nicht. Es wird auf die richtige Weise behandelt.

  • Schaltsekunden sollte man durch riesige Raketen am Äquator ersetzen. Nicht die Uhren anpassen, sondern den Planeten.

    • Wenn ein Rechenfehler die Erde zu stark verlangsamt oder beschleunigt, wäre das wohl nicht sehr lustig.
      In der islamischen Überlieferung über das Ende der Welt und den Antichristen (Dajjal) gibt es auch eine Stelle, in der so etwas tatsächlich geschieht. Es heißt: „Der erste Tag des Antichristen wird wie ein Jahr sein, der zweite Tag wie ein Monat und der dritte Tag wie eine Woche.“ Viele verstehen das wörtlich, also als kosmisches Ereignis, bei dem die Erdrotation tatsächlich langsamer wird und sich schließlich umkehrt, sodass die Sonne im Westen aufgeht. Das ist das letzte Zeichen für das Ende der Menschheit.

  • Ich frage mich, was es ausmacht, wenn die Epoche wegen Schaltsekunden 29 Sekunden länger zurückliegt, als date +%s impliziert.
    Viel wichtiger ist, dass sich alle auf irgendeine Zahl N einigen, die die aktuelle Zeit darstellt. Eine hypothetische Differenz von -29 Sekunden wirkt sich nicht auf die reale Welt aus. Man wird ja wohl keine Raketen-Zielroutine auf ein Ziel von vor 30 Jahren laufen lassen.
    Ich bin für die Abschaffung von Schaltsekunden, halte es aber nicht für hilfreich, die Zeitabweichung zu betonen. Auch wenn es streng genommen stimmt.

    • Man kann sich Situationen vorstellen, in denen die Dauer eines kurzen Ereignisses aus Start- und Endzeit berechnet wird. Wenn dieser Zeitraum eine Schaltsekunde einschließt, kann die Dauer je nach Art der Timestamp-Verarbeitung ziemlich unterschiedlich ausfallen.
      Wichtiger sind die Auswirkungen auf die Zukunft. Dass frühere Timestamps um ein paar Sekunden von einer einfachen Rechnung „jetzt - N Sekunden“ abweichen können, ist meist eher eine interessante Tatsache; wichtiger ist, dass zu irgendeinem künftigen Zeitpunkt möglicherweise alle Uhren erneut um eine Sekunde verschoben werden müssen. Es gibt viele reale Fälle, in denen es erheblichen Aufwand erfordert, das zu berücksichtigen.
    • Für manche Dinge ist es wichtig. Ohne solche hypothetischen Schaltsekunden wäre zum Beispiel der Sonnenstand zum lokalen Mittag um 29 Sekunden verschoben.