Unix -Zeit
1659277606
(2022-07-31T14: 26: 46+00: 00)

Im Computer, Unix -Zeit (auch bekannt als Epochenzeit, POSIX -Zeit,[1] Sekunden seit der Epoche,[2] Unix Timestamp oder Unix -Epoch -Zeit[3]) ist ein System zur Beschreibung a Zeitpunkt. Es ist die Anzahl der Anzahl von Sekunden das ist seit dem verstrichen Unix -Epoche, ausschließlich Sekundensprung. Die Unix -Epoche ist 00:00:00 koordinierte Weltzeit am 1. Januar 1970.
Die Unix -Zeit ist keine echte Darstellung von UTC, da ein Sprung zweiter und die zweite, bevor sie die gleiche Unix -Zeit (oder danach, abhängig) hat. Anders ausgedrückt, täglich in der Unix -Zeit genau enthält 86400 Sekunden,[2]; Keine Sekunden, die dem Tag aufgrund positiver oder negativer Sprungsekunden vom Tag hinzugefügt oder abtrahiert werden.
Die Unix -Zeit erschien ursprünglich als die Systemzeit von Unix, wird aber jetzt häufig im Computer verwendet, zum Beispiel von Dateisysteme; etwas Python -Sprache Bibliotheksfunktionen verarbeiten die Unix -Zeit.[4]
Definition
Zwei Schichten von Codierung bilden die Unix -Zeit. Die erste Schicht codiert einen Zeitpunkt als Skalar reelle Zahl Dies repräsentiert die Anzahl der Sekunden, die seit 00:00:00 vergangen sind UTC am Donnerstag, 1. Januar 1970.[5] Die zweite Schicht codiert diese Zahl als eine Abfolge von Bits oder Dezimalstellen.
Wie bei UTC Standard ist, bezeichnet dieser Artikel Tage mit dem Gregorianischer Kalender und zählt Zeiten innerhalb jeden Tags in Stunden, Minuten und Sekunden. Einige der Beispiele zeigen auch Internationale Atomzeit (TAI), ein anderes Zeitschema, das dieselben Sekunden verwendet und im selben Format wie UTC angezeigt wird, aber jeden Tag genau genau ist 86400 Sekunden lang, allmählich verlieren Synchronisation mit der Rotation der Erde mit einer Geschwindigkeit von ungefähr einem Sekunde pro Jahr.
Codierungszeit als Zahl
Unix Time ist eine einzelne signierte Zahl, die jede Sekunde erhöht, was es Computern erleichtert, zu speichern und zu manipulieren als herkömmliche Datumssysteme. Interpreter-Programme können es dann in ein menschliches lesbares Format umwandeln.
Das Unix Epoche ist die Zeit 00:00:00 UTC am 1. Januar 1970.[2] Es gibt ein Problem mit dieser Definition, in dem UTC erst 1972 in seiner gegenwärtigen Form existierte. Dieses Problem wird unten erörtert. Für die Kürze verwendet der Rest dieses Abschnitts ISO 8601 Datums- und Uhrzeitformat, bei dem die UNIX-Epoche 1970-01-01T00: 00: 00Z ist.
Die Unix -Zeitzahl ist in der UNIX -Epoche Null und steigt genau um 86400 pro Tag seit der Epoche. So 2004-09-16T00: 00: 00Z, 12677 Tage nach der Epoche wird durch die Unix -Zeitnummer dargestellt 12677 × 86400 = 1095292800. Dies kann auch von der Epoche mit negativen Zahlen nach hinten erweitert werden. So 1957-10-04T00: 00: 00Z, 4472 Tage vor der Epoche wird durch die Unix -Zeitnummer dargestellt –4472 × 86400 = –386380800. Dies gilt auch innerhalb von Tagen; Die Zeitnummer zu einem bestimmten Tageszeitpunkt ist die Anzahl der Sekunden, die seit der Mitternacht abgelaufen ist, die an diesem Tag zur Zeitnummer dieser Mitternacht hinzugefügt wurde.
Manchmal wird die Unix -Zeit fälschlicherweise als bezeichnet Epochenzeit, weil die Unix -Zeit auf einer Epoche basiert und aufgrund eines gemeinsamen Missverständnisses, dass die Unix -Epoche die einzige Epoche ist (oft genannt "die Epoche"[2]).[6][7][8]
Sekundensprung
Das obige Schema bedeutet, dass an einem normalen UTC -Tag, der eine Dauer von 86400 Sekunden ändert sich die Unix -Zeitzahl in a kontinuierlich Art und Weise über Mitternacht. Zum Beispiel entwickelt sich am Ende des Tages in den obigen Beispielen wie folgt die Zeitdarstellungen wie folgt:
Tai (17. September 2004) | UTC (16. bis 17. September 2004) | Unix -Zeit |
---|---|---|
2004-09-17t00: 00: 30.75 | 2004-09-16T23: 59: 58.75 | 1095379198.75 |
2004-09-17t00: 00: 31.00 | 2004-09-16T23: 59: 59.00 | 1095379199.00 |
2004-09-17T00: 00: 31.25 | 2004-09-16T23: 59: 59.25 | 1095379199.25 |
2004-09-17t00: 00: 31.50 | 2004-09-16T23: 59: 59.50 | 1095379199.50 |
2004-09-17t00: 00: 31.75 | 2004-09-16T23: 59: 59.75 | 1095379199.75 |
2004-09-17t00: 00: 32.00 | 2004-09-17t00: 00: 00.00 | 1095379200.00 |
2004-09-17T00: 00: 32.25 | 2004-09-17t00: 00: 00.25 | 1095379200.25 |
2004-09-17t00: 00: 32.50 | 2004-09-17t00: 00: 00.50 | 1095379200.50 |
2004-09-17T00: 00: 32.75 | 2004-09-17t00: 00: 00.75 | 1095379200.75 |
2004-09-17t00: 00: 33.00 | 2004-09-17t00: 00: 01.00 | 1095379201.00 |
2004-09-17t00: 00: 33.25 | 2004-09-17T00: 00: 01.25 | 1095379201.25 |
Wenn ein Schaltsekunde tritt auf, der UTC -Tag ist nicht genau 86400 Sekunden lang und die Unix -Zeitzahl (was immer um genau zunimmt 86400 jeden Tag) erlebt a Diskontinuität. Sprungsekunden können positiv oder negativ sein. Kein negativer Sprung Sekundensprung wurde jemals deklariert, aber wenn man es sein würde, würde die Unix -Zeitzahl am Ende eines Tages mit einem negativen Sprung Sekundensprung um 1 zum Beginn des nächsten Tages steigen. Während eines positiven Sprung zweitens am Ende eines Tages, der etwa alle anderthalb Jahre im Durchschnitt auftritt (Rückkehr zum Beginn des nächsten Tages). Dies ist beispielsweise auf streng konformen POSIX.1 -Systemen Ende 1998 passiert:
Tai (1. Januar 1999) | UTC (31. Dezember 1998 bis 1. Januar 1999) | Unix -Zeit |
---|---|---|
1999-01-01T00: 00: 29.75 | 1998-12-31T23: 59: 58.75 | 915148798.75 |
1999-01-01T00: 00: 30.00 | 1998-12-31T23: 59: 59.00 | 915148799.00 |
1999-01-01T00: 00: 30.25 | 1998-12-31T23: 59: 59.25 | 915148799.25 |
1999-01-01T00: 00: 30.50 | 1998-12-31T23: 59: 59,50 | 915148799.50 |
1999-01-01T00: 00: 30.75 | 1998-12-31T23: 59: 59.75 | 915148799.75 |
1999-01-01T00: 00: 31.00 | 1998-12-31T23: 59: 60.00 | 915148800.00 |
1999-01-01T00: 00: 31.25 | 1998-12-31T23: 59: 60.25 | 915148800.25 |
1999-01-01T00: 00: 31.50 | 1998-12-31T23: 59: 60.50 | 915148800.50 |
1999-01-01T00: 00: 31.75 | 1998-12-31T23: 59: 60.75 | 915148800.75 |
1999-01-01T00: 00: 32.00 | 1999-01-01T00: 00: 00.00 | 915148800.00 |
1999-01-01T00: 00: 32.25 | 1999-01-01T00: 00: 00.25 | 915148800.25 |
1999-01-01T00: 00: 32.50 | 1999-01-01T00: 00: 00.50 | 915148800.50 |
1999-01-01T00: 00: 32.75 | 1999-01-01T00: 00: 00.75 | 915148800.75 |
1999-01-01T00: 00: 33.00 | 1999-01-01T00: 00: 01.00 | 915148801.00 |
1999-01-01T00: 00: 33.25 | 1999-01-01T00: 00: 01.25 | 915148801.25 |
Unix -Zeitzahlen werden im zweiten Mal nach einem positiven Sprung Second wiederholt. Die Unix -Zeitnummer 1483142400 ist also mehrdeutig: Es kann sich entweder auf den Beginn des Leap Second (2016-12-31 23:59:60) oder auf das Ende eines Sekunde später beziehen, eine Sekunde später (2017-01-01 00:00:00). In dem theoretischen Fall, wenn ein negativer Sprung Sekundensprung auftritt, wird keine Unklarheit verursacht, sondern es gibt eine Reihe von Unix -Zeitzahlen, die sich nicht auf einen Punkt in der UTC -Zeit beziehen.
Eine UNIX -Uhr wird häufig mit einer anderen Art von positivem Sprung -Second -Handling implementiert, das mit dem verbunden ist Netzwerkzeitprotokoll (NTP). Dies ergibt ein System, das nicht dem POSIX -Standard entspricht. Weitere Informationen finden Sie im folgenden Abschnitt über NTP.
Wenn Sie sich mit Perioden befassen, die keinen UTC -Sprung aufweisen, ist die Differenz zwischen zwei Unix -Zeitzahlen in Sekunden des Zeitraums zwischen den entsprechenden Zeitpunkten gleich der Dauer. Dies ist eine gemeinsame Computertechnik. Wenn jedoch Sprungsekunden auftreten, geben solche Berechnungen die falsche Antwort. In Anwendungen, bei denen diese Genauigkeit erforderlich ist, ist es erforderlich, eine Tabelle mit Leap -Sekunden beim Umgang mit Unix -Zeiten zu konsultieren, und es ist häufig vorzuziehen, eine andere Zeitcodierung zu verwenden, die nicht an diesem Problem leidet.
Eine Unix -Zeitnummer kann leicht in eine UTC -Zeit umgewandelt werden, indem der Quotient und der Modul der Unix -Zeitnummer, Modulo 86400. Der Quotient ist die Anzahl der Tage seit der Epoche, und der Modul ist die Anzahl der Sekunden seit Mitternacht UTC an diesem Tag. Wenn eine Unix -Zeitnummer angegeben ist, die aufgrund eines positiven Sprung zweitens mehrdeutig ist, interpretiert dieser Algorithmus ihn kurz nach Mitternacht. Es erzeugt nie eine Zeit, die während eines Sprungsekundes stattfindet. Wenn eine Unix -Zeitnummer angegeben ist, die aufgrund eines negativen Sprung zweitens ungültig ist, generiert sie eine ebenso ungültige UTC -Zeit. Wenn diese Bedingungen signifikant sind, müssen eine Tabelle von Sekunden konsultiert werden, um sie zu erkennen.
Nicht-synchrone Netzwerkzeitprotokollbasierte Variante
Häufig a Mühlen-Style UNIX -Uhr wird mit dem Leap -Second -Handling implementiert, der mit der Änderung der Unix -Zeitnummer nicht synchron ist. Die Zeitzahl nimmt zunächst ab, wo ein Sprung aufgetreten sein sollte, und springt dann 1 Sekunde nach dem Sprung auf die richtige Zeit. Dies erleichtert die Implementierung und wird von Mills 'Papier beschrieben.[9] Dies ist, was über einen positiven Sprung Sekundensprung passiert:
Tai (1. Januar 1999) | UTC (31. Dezember 1998 bis 1. Januar 1999) | Bundesland | UNIX -Uhr |
---|---|---|---|
1999-01-01T00: 00: 29.75 | 1998-12-31T23: 59: 58.75 | Time_ins | 915148798.75 |
1999-01-01T00: 00: 30.00 | 1998-12-31T23: 59: 59.00 | Time_ins | 915148799.00 |
1999-01-01T00: 00: 30.25 | 1998-12-31T23: 59: 59.25 | Time_ins | 915148799.25 |
1999-01-01T00: 00: 30.50 | 1998-12-31T23: 59: 59,50 | Time_ins | 915148799.50 |
1999-01-01T00: 00: 30.75 | 1998-12-31T23: 59: 59.75 | Time_ins | 915148799.75 |
1999-01-01T00: 00: 31.00 | 1998-12-31T23: 59: 60.00 | Time_ins | 915148800.00 |
1999-01-01T00: 00: 31.25 | 1998-12-31T23: 59: 60.25 | Time_oop | 915148799.25 |
1999-01-01T00: 00: 31.50 | 1998-12-31T23: 59: 60.50 | Time_oop | 915148799.50 |
1999-01-01T00: 00: 31.75 | 1998-12-31T23: 59: 60.75 | Time_oop | 915148799.75 |
1999-01-01T00: 00: 32.00 | 1999-01-01T00: 00: 00.00 | Time_oop | 915148800.00 |
1999-01-01T00: 00: 32.25 | 1999-01-01T00: 00: 00.25 | ZEIT WARTET | 915148800.25 |
1999-01-01T00: 00: 32.50 | 1999-01-01T00: 00: 00.50 | ZEIT WARTET | 915148800.50 |
1999-01-01T00: 00: 32.75 | 1999-01-01T00: 00: 00.75 | ZEIT WARTET | 915148800.75 |
1999-01-01T00: 00: 33.00 | 1999-01-01T00: 00: 01.00 | ZEIT WARTET | 915148801.00 |
1999-01-01T00: 00: 33.25 | 1999-01-01T00: 00: 01.25 | ZEIT WARTET | 915148801.25 |
Dies kann ordnungsgemäß dekodiert werden, indem auf die Variable Second State für die Second -State achtet, die eindeutig angibt, ob der Sprung noch durchgeführt wurde. Die staatlich variable Änderung ist mit dem Sprung synchron.
Eine ähnliche Situation tritt mit einem negativen Sprung auf Sekunde auf, bei dem die zweite, die übersprungen wird, etwas zu spät ist. Sehr kurz zeigt das System eine nominell unmögliche Zeitnummer, dies kann jedoch von der erkannt werden Time_del Zustand und korrigiert.
In dieser Art von System verstößt die UNIX -Zeitzahl gegen POSIX um beide Arten von Sprung. Durch das Sammeln der Variablen "Second State" zusammen mit der Zeitnummer ermöglicht ein eindeutiges Dekodieren, sodass die richtige POSIX -Zeitnummer bei Bedarf generiert werden kann, oder die vollständige UTC -Zeit kann in einem geeigneteren Format gespeichert werden.
Die Dekodierungslogik, die erforderlich ist, um mit diesem Stil der Unix-Uhr fertig zu werden, würde auch eine hypothetische POSIX-Conforming-Uhr mit derselben Schnittstelle korrekt dekodieren. Dies würde erreicht werden, indem Sie die angeben Time_ins Zustand während der gesamten Einführungssprung Sekunde und dann anzeigen ZEIT WARTET In der gesamten folgenden Sekunde, während sie die Sekunden wiederholt. Dies erfordert eine synchrone Sprungbreite. Dies ist wahrscheinlich der beste Weg, um die UTC -Zeit in der UNIX -Uhrform über eine Unix -Schnittstelle auszudrücken, wenn die zugrunde liegende Uhr durch Leap -Sekunden grundlegend nicht verdoppt wird.
Tai-basierte Variante
Eine andere, viel seltenere, nicht konforme Variante der Unix Time-Keeping beinhaltet die Kodierung von Tai anstelle von UTC.[10] Einige Linux -Systeme sind auf diese Weise konfiguriert.[11] Da Tai keinen Schaltsekunden hat und jeder Tai-Tag genau 86400 Sekunden lang ist, ist diese Codierung tatsächlich eine reine lineare Anzahl von Sekunden, die seit 1970-01-01T00: 00: 10 verstrichen sind Tai. Dies erleichtert die Zeitintervallarithmetik viel. Zeitwerte aus diesen Systemen leiden nicht unter der Unklarheit, die POSIX-Systeme oder NTP-gesteuerte Systeme streng entsprechen.
In diesen Systemen ist es erforderlich, eine Tabelle von Leap Sekunden zu konsultieren, um die korrekte Konvertierung zwischen UTC und der Pseudo-Unix-Zeit-Darstellung zu konvertieren. Dies ähnelt der Art und Weise, in welchen Zeitzonentabellen konvertiert werden müssen, um zu und von Zivilzeit; das IANA -Zeitzonendatenbank Enthält Leap-Second-Informationen und der von derselbe Quelle verfügbare Beispielcode verwendet diese Informationen, um zwischen TAI-basierten Zeitstempeln und lokaler Zeit umzuwandeln. Die Konvertierung läuft auch in Definitionsproblemen vor dem Beginn der aktuellen UTC -Form von 1972 (siehe Abschnitt UTC -Basis unter).
Dieses TAI-basierte System ist trotz seiner oberflächlichen Ähnlichkeit keine Unix-Zeit. Es codiert Zeiten mit Werten, die sich von den POSIX -Zeitwerten um mehrere Sekunden unterscheiden. Eine Version dieses Systems, in der die Epoche für die Tai-basierte Zeit 1970-01-01T00: 00: 00 war TAI statt 1970-01-01T00: 00: 10 Tai wurde zur Aufnahme in ISO Cs vorgeschlagen time.h
, aber nur der UTC -Teil wurde 2011 akzeptiert.[12] A tai_clock
existiert jedoch in C ++ 20.
Die Nummer darstellen
Eine Unix -Zeitnummer kann in jedem Formular dargestellt werden, mit dem Zahlen dargestellt werden können. In einigen Anwendungen wird die Zahl einfach textuell als eine Zeichenfolge von Dezimalstellen dargestellt, was nur triviale zusätzliche Probleme aufwirft. Bestimmte binäre Darstellungen von Unix -Zeiten sind jedoch besonders signifikant.
Die Unix time_t
Datentyp, der einen Zeitpunkt darstellt, ist auf vielen Plattformen a Signierte ganze Zahltraditionell von 32 Bits (Siehe jedoch unten), um die Unix -Zeitnummer direkt zu codieren, wie im vorhergehenden Abschnitt beschrieben. 32 Bit zu sein bedeutet, dass es insgesamt eine Reichweite von etwa 136 Jahren abdeckt. Das minimale darstellbare Datum ist Freitag 1901-12-13, und das maximale darstellbare Datum ist Dienstag 2038-01-19. Eine Sekunde nach 03:14:07 UTC 2038-01-19 Diese Darstellung wird Überlauf in dem sogenannten als die Jahr 2038 Problem.
In einigen neueren Betriebssystemen, time_t
wurde auf 64 Bit erweitert. Dies erweitert die Zeiten, die in beiden Richtungen um ungefähr 292 Milliarden Jahre dargestellt werden können, was mehr als zwanzig Mal der Gegenwart ist Alter des Universums pro Richtung.
Es gab ursprünglich einige Kontroversen darüber, ob die Unix time_t
sollte unterschrieben oder nicht signiert werden. Wenn sie nicht unterzeichnet worden wäre, würde sich das Reichweite in der Zukunft verdoppelt und den 32-Bit-Überlauf (um 68 Jahre) verschieben. Es wäre jedoch nicht in der Lage, Zeiten vor der Epoche zu repräsentieren. Der Konsens ist für time_t
Unterzeichnung zu sein, und dies ist die übliche Praxis. Die Softwareentwicklungsplattform für Version 6 der Qnx Das Betriebssystem hat ein nicht signiertes 32-Bit time_t
, obwohl ältere Veröffentlichungen einen signierten Typ verwendeten.
Das Posix und Offene Gruppe Die UNIX -Spezifikationen umfassen die C Standardbibliothek, einschließlich der Zeittypen und Funktionen, die in der definiert sind
Header-Datei. Der ISO C Standard gibt an, dass time_t
Muss ein arithmetischer Typ sein, schreibt jedoch keinen bestimmten Typ oder eine bestimmte Codierung dafür vor. POSIX erfordert time_t
ein ganzzahliger Typ sein, aber nicht vorschreibt, dass er unterschrieben oder nicht signiert wird.
UNIX hat keine Tradition darin, die Unix-Zeitzahlen der Nichtteger unmittelbar als binäre Fraktionen direkt darzustellen. Stattdessen werden Zeit zusammengesetzte Datentypen Das besteht aus zwei Ganzzahlen, die erste ist a time_t
(der integrale Teil der Unix -Zeit) und der zweite der bruchteilige Teil der Zeitzahl in Millionstel (in Struct Timeval
) oder Milliarden (in Struct Timesspec
).[13][14] Diese Strukturen liefern a Dezimal-basierend Fixpunkt Datenformat, das für einige Anwendungen nützlich ist, und für andere zu konvertieren.
UTC -Basis
Die gegenwärtige Form von UTC mit LEAP Sekunden wird erst ab dem 1. Januar 1972 definiert. Zuvor gab es seit dem 1. Januar 1961 eine ältere Form von UTC, in der nicht nur gelegentliche Zeitschritte vorhanden waren, die nach Nicht-Intenger standen Die Anzahl der Sekunden, aber auch die UTC -Sekunde war etwas länger als die SI -Sekunde und änderte sich regelmäßig, um die Rotation der Erde kontinuierlich zu approximieren. Vor 1961 gab es keine UTC, und vor 1958 gab es keine weit verbreitete Verbreitung atomare Zeitmessung; In diesen Epochen eine Annäherung an eine Annäherung an mittlere Greenwich-Zeit (direkt auf der Erdrotation basierend) wurde anstelle eines atomaren Zeitrahmens verwendet.
Die genaue Definition der Unix -Zeit als Codierung von UTC ist nur unumstritten, wenn sie auf die vorliegende Form von UTC angewendet wird. Die UNIX -Epoche, die vor dem Beginn dieser UTC -Form vorhanden ist Die Anzahl der Tage ist alles, was für die Unix -Zeit von Bedeutung ist.
Die Bedeutung der Unix -Zeitwerte unten +63072000 (d. H. Vor dem 1. Januar 1972) ist nicht genau definiert. Die Grundlage solcher Unix -Zeiten wird am besten als nicht spezifizierte Annäherung an UTC verstanden. Computer dieser Ära ließen die Uhren selten genau eingestellt, um in jedem Fall aussagekräftige Zeitstempel unter Sekunde zu liefern. Die Unix-Zeit ist keine geeignete Möglichkeit, Zeiten vor 1972 in Anwendungen zu repräsentieren, die eine Präzision in der Sekunde erfordern. Solche Anwendungen müssen zumindest definieren, welche Form von UT oder GMT sie verwenden.
Ab 2009[aktualisieren]Die Möglichkeit, den Einsatz von Schaltsekunden in der zivilen Zeit zu beenden, wird berücksichtigt.[15] Ein wahrscheinliches Mittel zur Ausführung dieser Änderung besteht darin, eine neue Zeitskala zu definieren, die genannt wird Internationale ZeitDas ist zunächst mit UTC übereinstimmt, hat jedoch danach keinen Sprungsekunden und bleibt somit in einem konstanten Versatz von TAI. In diesem Fall ist es wahrscheinlich, dass die Unix -Zeit in Bezug auf diese neue Zeitskala anstelle von UTC prospektiv definiert wird. Die Unsicherheit darüber, ob dies auftreten wird, macht die prospektive Unix -Zeit nicht weniger vorhersehbar als bereits: Wenn UTC einfach keine weiteren Sprungsekunden haben würde, wäre das Ergebnis das gleiche.
Geschichte
Die frühesten Versionen der Unix Time hatten eine 32-Bit-Ganzzahl-Inkrementierung mit einer Rate von 60Hz, welches die Rate der Systemuhr auf der Hardware der frühen Unix -Systeme war. Der Wert von 60 Hz erscheint in einigen Software -Schnittstellen immer noch. Die Epoche unterschied sich ebenfalls vom aktuellen Wert. Das Handbuch für das UNIX -Programmierer der ersten Ausgabe vom 3. November 1971 definiert die Unix -Zeit als "die Zeit seit 00:00:00, 1. Januar 1971, gemessen in den sechzigsten Zeiten einer zweiten".[16]
Das Benutzerhandbuch kommentierte auch, dass "der chronologisch gesinnte Benutzer feststellt, dass 2 ** 32 Sechzigste einer Sekunde nur etwa 2,5 Jahre sind". Aufgrund dieser begrenzten Reichweite wurde die Epoche mehr als einmal neu definiert, bevor die Rate auf 1 Hz geändert wurde und die Epoche auf den aktuellen Wert vom 1. Januar 1970 00:00:00 UTC eingestellt wurde. Dies ergab eine Reichweite von etwa 136 Jahren, die die Hälfte davon vor 1970 und die Hälfte danach.
Wie aus der oben angegebenen Definition angegeben, war die Unix -Zeitskala ursprünglich eine einfache lineare Darstellung der Zeit, die seit einer Epoche verstrichen ist. Es gab jedoch keine Berücksichtigung der Details der Zeitskalen, und es wurde implizit angenommen, dass bereits eine einfache lineare Zeitskala verfügbar und vereinbart wurde. Die Definition des ersten Ausgabehandbuchs gibt nicht einmal an, welche Zeitzone verwendet wird. Mehrere spätere Probleme, einschließlich der Komplexität der vorliegenden Definition, resultieren aus der Unix -Zeit, die allmählich durch die Verwendung definiert und von Anfang an vollständig definiert wurden.
Wann Pox.1 Wurde geschrieben, die Frage stellte sich auf, wie man genau definiert werden kann time_t
Angesichts der Sekunden. Der POSIX -Komitee prüfte, ob die Unix -Zeit wie beabsichtigt eine lineare Anzahl von Sekunden seit der Epoche auf Kosten der Komplexität bei Umbauten mit ziviler Zeit oder einer Vertretung der zivilen Zeit auf Kosten der Inkonsistenz rund Sekunden bleiben sollte. Computeruhren der Ära waren nicht ausreichend genau so eingestellt, dass sie auf die eine oder andere Weise einen Präzedenzfall bilden.
Das POSIX -Komitee wurde von Argumenten gegen Komplexität in den Bibliotheksfunktionen beeinflusst und definierte die Unix -Zeit in Bezug auf die Elemente der UTC -Zeit fest. Diese Definition war so einfach, dass sie nicht einmal das gesamte umfasste Schaltjahr Herrschaft des gregorianischen Kalenders und würde 2100 ein Schaltjahr machen.
Die Ausgabe von POSIX von 2001.1 korrigierte die fehlerhafte Schaltjahrsregel in der Definition der Unix -Zeit, behielt jedoch die wesentliche Definition der Unix -Zeit als Codierung von UTC und nicht als lineare Zeitskala bei. Seit Mitte der 1990er Jahre wurden Computeruhren routinemäßig mit ausreichender Präzision für diese Angelegenheit eingestellt, und sie wurden am häufigsten unter Verwendung der UTC-basierten Definition der Unix-Zeit festgelegt. Dies hat zu einer erheblichen Komplexität bei UNIX -Implementierungen und in der geführt Netzwerkzeitprotokoll, um Schritte in der Unix -Zeitnummer auszuführen, wenn Sprungsekunden auftreten.
Bemerkenswerte Ereignisse in der Unix -Zeit
UNIX -Enthusiasten haben eine Geschichte, in der "Time_t Parties" (ausgesprochen "Zeit gehalten werden Teepartys") um signifikante Werte der Unix -Zeitzahl zu feiern.[17][18] Diese sind direkt analog zu der Neujahr Feierlichkeiten, die bei der Änderung des Jahres in vielen Kalendern stattfinden. Mit der Verbreitung der Unix -Zeit hat sich auch die Praxis, seine Meilensteine zu feiern. Normalerweise sind es Zeitwerte, die runde Zahlen in sind Dezimal das werden gefeiert, nach der Unix -Konvention des Betrachtens time_t
Werte in Decimal. Unter einigen Gruppen rund binär Zahlen werden ebenfalls gefeiert, z. B. +230 die am Samstag, den 10. Januar 2004, um 13:37:04 UTC ereignete.
Die Ereignisse, die diese feiern, werden normalerweise als "beschrieben" beschrieben "N Sekunden seit der UNIX -Epoche ", aber dies ist ungenau; wie oben diskutiert, aufgrund des Umgangs mit Schaltsekunden in der UNIX -Zeit ist die Anzahl der Sekunden verstrichen, da die Unix -Epoche für die Unix -Zeit für Zeiten später als die Epoche geringfügig größer ist als die Unix -Zeitnummer.
- Um 18:36:57 UTC am Mittwoch, 17. Oktober 1973, der erste Auftritt des Datums in ISO 8601 Format[a] (1973-10-17) Innerhalb der Ziffern der Unix -Zeit (119731017) fand statt.
- Um 01:46:40 UTC am Sonntag, dem 9. September 2001, The Unix Billennium (Unix -Zeitnummer 1000000000) wurde gefeiert.[19] Der Name Billennium ist ein Handkoffer von Milliarde und Millennium.[20][21] Einige Programme, die Zeitstempel unter Verwendung einer Textdarstellung gespeichert haben 1 Ziffern, fälschlicherweise vor früheren Zeiten sortiert 9 Ziffer. Zu den betroffenen Programmen gehörten die Bevölkerung Usenet Leser Knoten und Email Klient Kmail, Teil von Kde Desktop -Umgebung. Solche Fehler waren im Allgemeinen kosmetischer Natur und wurden schnell behoben, sobald Probleme sichtbar wurden. Das Problem hat auch viele betroffen Filtrix Dokumenteformatfilter mitgeliefert mit Linux Versionen von WordPerfect; Ein Patch wurde von der Benutzergemeinschaft erstellt, um dieses Problem zu lösen Corel Diese Version des Programms nicht mehr verkauft oder unterstützt.[22]
- Um 23:31:30 UTC am Freitag, 13. Februar 2009, die Dezimal Darstellung der Unix -Zeit erreicht 1234567890 Sekunden.[23] Google feierte dies mit einem Google Doodle.[24] Partys und andere Feierlichkeiten fanden weltweit unter verschiedenen technischen Subkulturen statt, um die zu feiern 1234567890th Second.[17][25]
- Um 03:33:20 Uhr UTC am Mittwoch, 18. Mai 2033 2000000000 Sekunden.
- Um 09:06:49 UTC am Freitag, 16. Juni 2034, entspricht der Unix -Zeitwert dem laufenden Jahr, Monat, Datum und Stunde (2034061609).
- Um 06:28:16 UTC am Donnerstag, 7. Februar 2036,, Netzwerkzeitprotokoll wird zur nächsten Epoche übergehen, da der in NTP verwendete 32-Bit-Zeitstempelwert (nicht signiert, aber basierend auf dem 1. Januar 1900) überlaufen wird. Dieser Datum liegt nahe am folgenden Datum, da der 136-jährige Bereich einer 32-Bit-Zahl von Sekunden nahe dem doppelt so hoch wie der 70-jährige Versatz zwischen den beiden Epochen liegt.
- Um 03:14:08 Uhr UTC am Dienstag, 19. Januar 2038, wird 32-Bit-Versionen des UNIX-Timestamps nicht mehr arbeiten, da es den größten Wert überfüllt, der in einer signierten 32-Bit-Zahl gehalten werden kann (((7fffffff16 oder 2147483647). Vor diesem Moment muss Software mit 32-Bit-Zeitstempel eine neue Konvention für Zeitstempel annehmen.[26] und Dateiformate mit 32-Bit-Zeitstempel müssen geändert werden, um größere Zeitstempel oder eine andere Epoche zu unterstützen. Wenn unverändert, wird die nächste Sekunde am Freitag fälschlicherweise mit 20:45:52 interpretiert 13. Dezember 1901 UTC. Dies wird als die bezeichnet Jahr 2038 Problem.
- Um 05:20:00 UTC am Samstag, den 24. Januar 2065 3000000000 Sekunden.
- Um 06:28:15 Uhr UTC am Sonntag, dem 7. Februar 2106, wird die Unix -Zeit erreichen Ffffffff16 oder 4294967295 Sekunden, die für Systeme, die die Zeit für 32-Bit-nicht signierte Ganzzahlen haben, die maximal erreichbare. Für einige dieser Systeme wird die nächste Sekunde am Donnerstag fälschlicherweise als 00:00:00 Uhr interpretiert 1. Januar 1970 UTC. Andere Systeme können einen Überlauffehler mit unvorhersehbaren Ergebnissen aufweisen.
- Um 15:30:08 UTC am Sonntag, 4. Dezember 292277026596,[27][28] Die Unix-Zeit überfüllt den größten Wert, der in einer unterschriebenen 64-Bit-Zahl gehalten werden kann. Diese Dauer beträgt fast das 22 -fache der geschätztes aktuelles Alter des Universums, welches ist 1.37×1010 (13,7 Milliarden) Jahre.
In Literatur und Kalender
Vernor Vinge'S Roman Eine Deepness am Himmel Beschreibt in Zukunft eine zivile zivilisation tausende von tausende von space brating, die immer noch die UNIX -Epoche verwendet. Das "Programmierer-Archäologe"Verantwortlich für die Suche und Aufrechterhaltung des nutzbaren Codes in reifen Computersystemen ist zunächst der Ansicht, dass sich die Epoche auf die Zeit bezieht, wann Der Mann ging zuerst auf den Mond, aber dann erkennt es, dass es "die 0-Sekunden eines der ersten Computerbetriebssysteme der Menschheit" ist.[29]
Siehe auch
Anmerkungen
- ^ zitiert rückwirkend seit der Veröffentlichung von ISO 8601 im Jahr 1988.
Verweise
- ^ "Die offenen Gruppenbasisspezifikationen Ausgabe 7, Begründung: Basisdefinitionen, Abschnitt A.4 Allgemeine Konzepte". Die offene Gruppe. Abgerufen 9. September 2019.
- ^ a b c d "Die offenen Gruppenbasisspezifikationen in Abschnitt 4.16 Sekunden seit der Epoche". Die offene Gruppe. Abgerufen 22. Januar 2017.
- ^ Matthew, Neil; Stones, Richard (2008). "Die Linux -Umgebung". Linux -Programmierung beginnen. Indianapolis, Indiana, USA: Wiley. p. 148. ISBN 978-0-470-14762-7.
- ^ "Zeit - Zeitzugriff und Conversions", Python -Dokumentation, abgerufen 25. Juli 2022
- ^ "Epoch Converter - UNIX Timestamp Converter". Epoch -Konverter. Abgerufen 12. Januar 2020.
- ^ "Umgang mit Zeitstempeln mit Formatdatum in Abkürzungen". Apple Inc. Abgerufen 19. Juni 2019.
- ^ "Rohdatumformat in CSV Exported Reports". International Business Machines Corporation (IBM). 22. April 2016. Abgerufen 19. Juni 2019.
- ^ "Zeitstempel von (Azure Stream Analytics)". Microsoft Corporation. Abgerufen 19. Juni 2019.
- ^ Mills, David L. (12. Mai 2012). "Die NTP -Zeitskala und Sprungsekunden". eecis.udel.edu. Abgerufen 21. August 2017.
- ^ "Präzisionszeitmessung". Quellen für Zeitzonen- und Tageslichtsparenzeitdaten.
- ^ "Zeitskalen". Netzwerkzeitprotokoll -Wiki. 24. Juli 2019. Abgerufen 12. Januar 2020.
- ^ Markus Kuhn. "Modernisierte API für ISO C". www.cl.cam.ac.uk.
- ^ "Timesspec". NETBSD -Handbuchseiten. 12. April 2011. Abgerufen 5. Juli 2019.
- ^ "time.h (0p)". Linux -Handbuch Seite. Abgerufen 5. Juli 2019.
- ^ McCarthy, D. D.; Seidelmann, P. K. (2009). Zeit - von der Erdrotation zur Atomphysik. Weinheim: Wiley - VCH Verlag GmbH & Co. Kgaa. p. 232. ISBN 978-3-527-40780-4.
- ^ UNIX -Programmierhandbuch (PDF) (1. Aufl.). 3. November 1971. Abgerufen 28. März 2012.
Zeit Gibt die Zeit seit 00:00:00, 1. Januar 1971, gemessen in sechzig Jahren einer Sekunde zurück.
- ^ a b Tweney, Dylan (12. Februar 2009). "Unix -Liebhaber zu feiern, als wäre es 1234567890". Verdrahtet.
- ^ "Slashdot | Datum +%s drehen 1111111111". 17. März 2005.[unzuverlässige Quelle?]
- ^ "Unix Time Facts & Trivia - Unix Time. Info". Archiviert von das Original am 27. Oktober 2017.
- ^ "Unix nähert sich das reife Alter von einer Milliarde". Elektromagnetisch.net. Archiviert von das Original am 13. April 2013. Abgerufen 6. Dezember 2012.
- ^ Neumann, Peter G. (15. Oktober 2001). "Die Risiken Digest Band 21: Ausgabe 69". Catless.ncl.ac.uk. Abgerufen 6. Dezember 2012.
- ^ "Technische Probleme". Linuxmafia.com. Abgerufen 21. August 2017.
- ^ Nixcraft. "Humor: Am Februar, Freitag 13, 2009, wird die Unix -Zeit 1234567890 sein". Cyberciti.biz. Abgerufen 6. Dezember 2012.
- ^ "Google 1234567890 Logo". Google Inc. Abgerufen 28. Januar 2013.
- ^ Ahmed, Murad (13. Februar 2009). "Beim dritten Schlag beträgt die Unix -Zeit 1234567890". Die Zeiten.
- ^ "Unix Time Stamp.com". Unixtimestamp.com. Abgerufen 12. Januar 2020.
- ^ Spinellis, Diomidis (7. April 2006). Codequalität: Die Open -Source -Perspektive. ISBN 9780321166074.
- ^ IDRBT -Arbeitspapier Nr. 9 Y2K38 - Ashutosh Saxena und Sanjay Rawat
- ^ Mashey, John R. (27. Dezember 2004). "Sprachen, Ebenen, Bibliotheken und Langlebigkeit". Warteschlange. 2 (9): 32–38. doi:10.1145/1039511.1039532. S2CID 28911378.
Externe Links
- UNIX -Programmierhandbuch, Erstausgabe
- Persönlicher Bericht über die POSIX -Entscheidungen durch Landon Curt Noll
- Clewett, James. 2.147.483.647 - das Ende der Zeit [UNIX].
- Chrono-kompatible Datumsalgorithmen auf niedriger Ebene - Algorithmen, um zwischen Gregorianischen und julianischen Daten und der Anzahl der Tage seit Beginn der Unix -Zeit umzuwandeln