Deutsch

Entwicklertools · Unix-Zeitstempelkonverter

Schaltsekunden und Unix-Zeit: Warum die Epoche so tut, als ob sie nicht existieren

· Hintergrund

Zeitstempel Unix-Zeit Zeitzonen

Eine Zeitleiste, die direkt von 23:59:59 bis Mitternacht verläuft
Original-ToolAcre-Vektorillustration

UTC hat seit 1972 Schaltsekunden eingefügt, aber die Unix-Zeit zählt sie einfach nicht, was bedeutet, dass einige Sekunden zweimal passiert sind. In diesem Beitrag wird erklärt, warum, was Schmierereien sind und warum die ganze Praxis eingestellt werden soll.

Das zweite, das zweimal passierte – ein 23:59:60 in einem System, ein wiederholtes 23:59:59 in einem anderen und ein Fehler bei der Schlüsselduplikatierung um Mitternacht

ToolAcre kann keine ISO-Zeile erzeugen, die mit `23:59:60` endet. Sein Test benennt die Schaltsekundengrenze und erwartet, dass ein Epochenwert als `2016-12-31T23:59:59.000Z` und der nächste als `2017-01-01T00:00:00.000Z` formatiert wird. Es gibt keine zusätzliche anzeigbare Sekunde dazwischen.

Diese Tatsache kann sich auf Protokolle auswirken, deren externe Quelle eine andere Konvention verwendet, aber dieses Repository enthält keine Beweise für Vorfälle mit doppelten Schlüsseln. Wenn in einem System wiederholte Bezeichnungen auftauchen, überprüfen Sie den Takt und den Speicherpfad, anstatt sie automatisch dem Konverter zuzuordnen.

Ein System, das für jede physische Sekunde eine eindeutige Bezeichnung erfordert, benötigt daher mehr Kontext als diese Unix-to-Date-Zuordnung. Der Konverter kann kein Etikett herstellen, das sein Modell weglässt.

ToolAcre erweist sich als nicht darstellbar 23:59:60; Vorfälle mit doppelten Schlüsseln werden nicht dokumentiert

Die Gliederung erläuterte die Atomzeit, die Erdrotation und eine Toleranzschwelle. Diese wissenschaftlichen und standardisierten Ansprüche werden nicht durch den Zeitstempelcode oder Tests bestätigt. Sie werden bewusst weggelassen und nicht aus dem Gedächtnis paraphrasiert. Der Mechanismus beweist hier nicht die Gründe für die globale Zeitnahmepolitik.

Für die Verwendung dieser Route sind die erforderlichen Beweise einfacher: Datums- und ISO-Ausgabe legen gewöhnliche Sekundenbezeichnungen offen, und die Epoche im POSIX-Stil schreitet über die getestete Grenze hinaus voran. Eine quellenbasierte Behandlung der Schaltsekunden-Governance würde maßgebliches Material erfordern, das über die zulässigen Repository-Pfade hinausgeht.

Diese Grenze ist explizit und nicht ausweichend: Softwaretests beantworten Repräsentationsfragen, während die Wissenschaftsgeschichte für diesen Zweck geschriebenes und nach ihren eigenen Bedingungen überprüftes Material benötigt.

Die physikalische Begründung für Schaltsekunden erfordert Quellen außerhalb dieses Repositorys

Das implementierte Modell verhält sich so, als ob zivile Tage auf seiner Achse 86,400 nummerierte Unix-Sekunden hätten. Aufeinanderfolgende ganzzahlige Eingaben unterscheiden sich um eine Sekunde, auch über die Jahresgrenze von 2016 hinweg. `fromEpoch` multipliziert jedes mit 1,000 und Date formatiert die resultierende Millisekundenzahl.

Die Bezeichnung „Ignorieren“ von Schaltsekunden beschreibt die beobachtbare Ausgabe: Kein eindeutiger Unix-Wert wird einem `:60`-Label zugeordnet. Dies bedeutet nicht, dass die Uhr jeder Maschine während einer echten Einfügung identisch weitergeht. Der Konverter akzeptiert eine Zählung; Die Host-Uhr wird nicht abgetastet oder diszipliniert.

Die Arithmetik über größere Bereiche folgt der gleichen Konvention. Das Subtrahieren zweier Unix-Werte misst also deren Zähldifferenz im POSIX-Stil, anstatt ausgelassene Sprungbezeichnungen zu rekonstruieren.

Die getestete Konvertierung hat keine Schaltsekundenbezeichnung zwischen aufeinanderfolgenden Epochenwerten

Systeme können Schritte, Wiederholungen oder Abstriche anwenden, aber das Repository identifiziert nicht, welche Anbieter welche Methode, in welchem Intervall oder mit welcher Formel verwenden. Die Veröffentlichung dieser Details ohne direkte Beweise würde zu einer betriebsgefährdenden Präzision führen. Dieser Artikel macht daher kein plattformspezifisches Taktversprechen.

Wenn Ereignisse in der Nähe einer Sprunggrenze von Bedeutung sind, bewahren Sie die Uhrdokumentation und die Rohwerte der Quelle auf. Zwei Systeme mit unterschiedlicher Handhabung können unterschiedlich sein, auch wenn beide Werte als UTC formatiert sind. Die Konvertierung allein kann ihr Stichprobenverhalten nicht in Einklang bringen oder eine ausgelassene Skalenunterscheidung wiederherstellen.

Die Wahl einer Laufzeit kann sich auch auf die kurzlebige Reihenfolge rund um das Ereignis auswirken. Behalten Sie monotone Zähler oder quellenspezifische Sequenzdaten bei, wenn diese Unterscheidung betrieblich wichtig ist.

Das Clock-Step- und Smear-Verhalten ist plattformspezifisch und wird hier nicht überprüft

Geben Sie 1,483,228,799 Sekunden ein: Das verifizierte ISO-Ergebnis ist `2016-12-31T23:59:59.000Z`. Erhöhen Sie die Eingabe einmal auf 1,483,228,800: Das Ergebnis ist `2017-01-01T00:00:00.000Z`. Das Subtrahieren der ganzen Zahlen ergibt eins, was der angezeigten Progression in diesem Modell entspricht.

Die lokalen Zeilen zeigen je nach Browser möglicherweise unterschiedliche Datumsangaben oder Offsets an, sie stammen jedoch von denselben Zeitpunkten. Verwenden Sie die ISO-Zeilen für die Grenzprüfung. Eine Änderung der lokalen Zone hat nichts damit zu tun, ob eine Schaltsekundenbezeichnung vorhanden ist.

Das Paar ist ein nützlicher Regressionstest, da es in den ISO-Zeichenfolgen keine Gebietsschemaabhängigkeit gibt. Es sperrt das Verhalten des Konverters direkt an der relevanten Kante.

Arbeitsbeispiel: die getestete 2016-Grenze des Repositorys

Die Arbeitsmappe verwies auf eine 2022-Lösung und eine zukünftige Frist. In den Umsetzungsnachweisen sind keine Standards oder Richtlinienquellen enthalten, daher werden hier weder Datum noch Prognose angegeben. Die Richtlinien zur Zeitmessung können sich ändern und verdienen zum Zeitpunkt der Veröffentlichung eine aktuelle, maßgebliche Zitierung.

Das Weglassen dieser Behauptung schwächt die Software-Leitlinien nicht. Für vorhandene Daten müssen weiterhin Maßstab, Einheit und Taktquelle dokumentiert werden. Das aktuelle Verhalten eines Konverters bleibt unabhängig von Entscheidungen über die zukünftige Zivilpraxis überprüfbar.

Betreuer können den Richtlinienkontext später hinzufügen, indem sie die Lösung direkt zitieren. Bis dahin ist der Ausschluss einer Frist zutreffender als die Veröffentlichung einer nicht unterstützten Zukunftsgarantie.

Zukünftige politische Beschlüsse werden ohne maßgebliche Quelle weggelassen

TAI, GPS und andere Maßstäbe können die Zeit unterschiedlich darstellen, aber ToolAcre bietet dafür keine Selektor- oder Offset-Tabelle an. Das Einfügen einer solchen Zählung als Unix-Sekunden wendet lediglich die Interpretation im POSIX-Stil 1970 an. Ein lesbares Ergebnis kann dennoch semantisch falsch sein.

Transformieren Sie andere Skalen mit einer Quelle, die ihren Ursprung und ihre Beziehung zum relevanten Zeitpunkt definiert, und überprüfen Sie dann den resultierenden Unix-Wert. Fügen Sie keine Erinnerungskonstante hinzu: Beziehungen, die einen Sprungverlauf beinhalten, sind genau der Punkt, an dem die Arithmetik ohne Quellenangabe brüchig wird.

Das Fehlen eines Modus ist in den drei Einheitenoptionen der Benutzeroberfläche sichtbar. Keine ändert die Zeitskala; Automatic wählt lediglich zwischen zwei Unix-Auflösungen.

Andere Zeitskalen liegen außerhalb der Implementierung dieses Unix-Konverters

Für diesen Konverter ist die verifizierte Regel ein direkter Schritt von 23:59:59 zu 00:00:00 an der getesteten Grenze. Dieses Modell unterstützt die gewöhnliche Epochenarithmetik und erklärt, warum keine `:60`-Ausgabe erscheint. Es wird nicht zertifiziert, wie sich eine Betriebssystemuhr verhält, während die tatsächliche Grenze überschritten wird.

Wenn es auf Präzision bei der Handhabung von Sprüngen ankommt, ist die Konvertierung der letzte Präsentationsschritt und nicht die Beweisquelle. Sammeln Sie zunächst die Dokumentation im Taktmaßstab, das Synchronisationsverhalten und die Rohereignisfelder. ToolAcre kann dann zeigen, was eine deklarierte Unix-Anzahl unter seinem getesteten Modell bedeutet.

Bei gewöhnlichen Protokollen außerhalb der Sprunggrenzen ändert diese Nuance selten die Anzeige. In der Nähe sensibler Grenzen verhindert die Benennung des Modells jedoch falsche Behauptungen der physischen Sekundentreue.