Unixzeit
Die Unix-Zeit (auch bekannt als Epochenzeit, Posix-Zeit, Sekunden seit der Epoche oder UNIX-Epochenzeit) ist ein System zur Beschreibung eines Zeitpunkts. Sie ist die Anzahl der Sekunden, die seit der Unix-Epoche verstrichen sind, ausgenommen Schaltsekunden. Die Unix-Epoche ist 00:00:00 UTC am 1. Januar 1970 (ein beliebiges Datum). Die Unix-Zeit ist nichtlinear, wobei eine Schaltsekunde die gleiche Unix-Zeit hat wie die Sekunde davor (oder danach, abhängig von der Implementierung), so dass jeder Tag so behandelt wird, als ob er genau 86400 Sekunden enthielte, ohne dass dem Tag aufgrund von positiven oder negativen Schaltsekunden Sekunden hinzugefügt oder abgezogen werden. Aufgrund dieser Behandlung von Schaltsekunden ist die Unix-Zeit keine genaue Darstellung der UTC-Zeit. ⓘ
Die Unix-Zeit wird in vielen Betriebssystemen und Dateiformaten verwendet. In Unix-ähnlichen Betriebssystemen ist date ein Befehl, der die aktuelle Zeit ausgibt oder setzt; standardmäßig wird die Zeit in der Systemzeitzone ausgegeben oder gesetzt, aber mit der Option -u Flagge wird die Zeit in UTC ausgedruckt oder gesetzt und mit der TZ Umgebungsvariable auf eine bestimmte Zeitzone verweist, wird die Zeit in dieser Zeitzone gedruckt oder gesetzt. ⓘ
Definition
Die Unix-Zeit besteht aus zwei Kodierungsschichten. Die erste Schicht kodiert einen Zeitpunkt als skalare reelle Zahl, die die Anzahl der Sekunden darstellt, die seit 00:00:00 UTC Donnerstag, 1. Januar 1970, vergangen sind. Die zweite Schicht kodiert diese Zahl als eine Folge von Bits oder Dezimalziffern. ⓘ
Wie bei UTC üblich, werden in diesem Artikel die Tage nach dem gregorianischen Kalender bezeichnet und die Zeiten innerhalb jedes Tages in Stunden, Minuten und Sekunden gezählt. Einige der Beispiele zeigen auch die Internationale Atomzeit (TAI), ein anderes Zeitschema, das die gleichen Sekunden verwendet und im gleichen Format wie UTC angezeigt wird, aber jeder Tag ist genau 86400 Sekunden lang und verliert allmählich die Synchronisation mit der Erdrotation mit einer Rate von etwa einer Sekunde pro Jahr. ⓘ
Kodierung der Zeit als Zahl
Die Unix-Zeit ist eine einzelne vorzeichenbehaftete Zahl, die jede Sekunde inkrementiert, wodurch sie für Computer einfacher zu speichern und zu verarbeiten ist als herkömmliche Datumssysteme. Interpreterprogramme können sie dann in ein für Menschen lesbares Format umwandeln. ⓘ
Die Unix-Epoche ist die Zeit 00:00:00 UTC am 1. Januar 1970. Diese Definition ist insofern problematisch, als es UTC in seiner heutigen Form erst seit 1972 gibt; auf dieses Problem wird weiter unten eingegangen. Der Rest dieses Abschnitts verwendet der Kürze halber das ISO 8601 Datums- und Zeitformat, in dem die Unix-Epoche 1970-01-01T00:00:00Z lautet. ⓘ
Die Unix-Zeitnummer ist bei der Unix-Epoche null und erhöht sich seit der Epoche um genau 86400 pro Tag. Somit wird 2004-09-16T00:00:00Z, 12677 Tage nach der Epoche, durch die Unix-Zeitnummer 12677 × 86400 = 1095292800 dargestellt. Dies kann auch rückwärts von der Epoche ausgedehnt werden, indem man negative Zahlen verwendet; so wird 1957-10-04T00:00:00Z, 4472 Tage vor der Epoche, durch die Unix-Zeitnummer -4472 × 86400 = -386380800 dargestellt. Dies gilt auch innerhalb von Tagen; die Zeitnummer zu einem bestimmten Zeitpunkt eines Tages ist die Anzahl der Sekunden, die seit der Mitternacht, mit der dieser Tag beginnt, vergangen sind, addiert zur Zeitnummer dieser Mitternacht. ⓘ
Manchmal wird die Unix-Zeit fälschlicherweise als Epochenzeit bezeichnet, weil die Unix-Zeit auf einer Epoche basiert und weil es ein weit verbreitetes Missverständnis ist, dass die Unix-Epoche die einzige Epoche ist (oft "die Epoche" genannt). ⓘ
Schaltsekunden
Das obige Schema bedeutet, dass sich an einem normalen UTC-Tag, der eine Dauer von 86400 Sekunden hat, die Unix-Zeitnummer kontinuierlich über Mitternacht hinaus ändert. Am Ende des Tages, der in den obigen Beispielen verwendet wird, verlaufen die Zeitdarstellungen beispielsweise 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 eine Schaltsekunde auftritt, ist der UTC-Tag nicht genau 86400 Sekunden lang, und die Unix-Zeitnummer (die sich jeden Tag immer um genau 86400 Sekunden erhöht) erfährt eine Diskontinuität. Schaltsekunden können positiv oder negativ sein. Es wurde noch nie eine negative Schaltsekunde deklariert, aber wenn dies der Fall wäre, würde die Unix-Zeitnummer am Ende eines Tages mit einer negativen Schaltsekunde zum Beginn des nächsten Tages um 1 hochspringen. Bei einer positiven Schaltsekunde am Ende eines Tages, die im Durchschnitt etwa alle anderthalb Jahre vorkommt, steigt die Unix-Zeitnummer während der Schaltsekunde kontinuierlich bis zum nächsten Tag an und springt dann am Ende der Schaltsekunde um 1 zurück (zurück zum Beginn des nächsten Tages). Dies geschah zum Beispiel auf streng POSIX.1-konformen Systemen Ende 1998:
| 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-Zeitnummern werden in der unmittelbar auf eine positive Schaltsekunde folgenden Sekunde wiederholt. Die Unix-Zeitnummer 1483142400 ist daher mehrdeutig: Sie kann sich entweder auf den Beginn der Schaltsekunde (2016-12-31 23:59:60) oder auf das Ende der Schaltsekunde, eine Sekunde später (2017-01-01 00:00:00), beziehen. In dem theoretischen Fall, dass eine negative Schaltsekunde auftritt, wird keine Mehrdeutigkeit verursacht, sondern es gibt einen Bereich von Unix-Zeitnummern, die sich auf keinen Punkt der UTC-Zeit beziehen. ⓘ
Eine Unix-Uhr wird oft mit einer anderen Art von positiver Schaltsekundenbehandlung implementiert, die mit dem Network Time Protocol (NTP) verbunden ist. Dies führt zu einem System, das nicht mit dem POSIX-Standard konform ist. Siehe den Abschnitt über NTP weiter unten für weitere Details. ⓘ
Wenn es sich um Zeiträume handelt, die keine UTC-Schaltsekunde umfassen, ist die Differenz zwischen zwei Unix-Zeitnummern gleich der Dauer des Zeitraums in Sekunden zwischen den entsprechenden Zeitpunkten. Dies ist eine übliche Rechentechnik. In Fällen, in denen Schaltsekunden auftreten, führen solche Berechnungen jedoch zu einer falschen Antwort. In Anwendungen, in denen diese Genauigkeit erforderlich ist, ist es notwendig, eine Tabelle mit Schaltsekunden zu konsultieren, wenn man mit Unix-Zeiten arbeitet, und es ist oft besser, eine andere Zeitkodierung zu verwenden, die nicht unter diesem Problem leidet. ⓘ
Eine Unix-Zeitnummer lässt sich leicht in eine UTC-Zeit umwandeln, indem man den Quotienten und den Modulus der Unix-Zeitnummer, modulo 86400, nimmt. Der Quotient ist die Anzahl der Tage seit der Epoche, und der Modulus ist die Anzahl der Sekunden seit Mitternacht UTC an diesem Tag. Wird eine Unix-Zeitnummer angegeben, die aufgrund einer positiven Schaltsekunde nicht eindeutig ist, interpretiert dieser Algorithmus sie als die Zeit kurz nach Mitternacht. Er erzeugt niemals eine Zeit, die während einer Schaltsekunde liegt. Wird eine Unix-Zeitnummer angegeben, die aufgrund einer negativen Schaltsekunde ungültig ist, wird eine ebenso ungültige UTC-Zeit erzeugt. Wenn diese Bedingungen von Bedeutung sind, muss eine Tabelle mit Schaltsekunden konsultiert werden, um sie zu erkennen. ⓘ
Nicht-synchrone Variante auf Basis des Network Time Protocol
Üblicherweise wird eine Unix-Uhr im Mills-Stil implementiert, bei der die Schaltsekundenbehandlung nicht synchron mit der Änderung der Unix-Zeitnummer erfolgt. Die Zeitnummer verringert sich zunächst an den Stellen, an denen ein Schaltvorgang hätte stattfinden sollen, und springt dann eine Sekunde nach dem Schaltvorgang auf die richtige Zeit. Dies erleichtert die Implementierung und wird in Mills' Dokument beschrieben. Dies geschieht bei einer positiven Schaltsekunde:
| TAI (1. Januar 1999) | UTC (31. Dezember 1998 bis 1. Januar 1999) | Zustand | Unix-Uhr |
|---|---|---|---|
| 1999-01-01T00:00:29.75 | 1998-12-31T23:59:58.75 | ZEIT_INS | 915148798.75 |
| 1999-01-01T00:00:30.00 | 1998-12-31T23:59:59.00 | ZEIT_INS | 915148799.00 |
| 1999-01-01T00:00:30.25 | 1998-12-31T23:59:59.25 | ZEIT_INS | 915148799.25 |
| 1999-01-01T00:00:30.50 | 1998-12-31T23:59:59.50 | ZEIT_INS | 915148799.50 |
| 1999-01-01T00:00:30.75 | 1998-12-31T23:59:59.75 | ZEIT_INS | 915148799.75 |
| 1999-01-01T00:00:31.00 | 1998-12-31T23:59:60.00 | ZEIT_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_WARTEN | 915148800.25 |
| 1999-01-01T00:00:32.50 | 1999-01-01T00:00:00.50 | ZEIT_WARTEN | 915148800.50 |
| 1999-01-01T00:00:32.75 | 1999-01-01T00:00:00.75 | ZEIT_WARTEN | 915148800.75 |
| 1999-01-01T00:00:33.00 | 1999-01-01T00:00:01.00 | ZEIT_WARTEN | 915148801.00 |
| 1999-01-01T00:00:33.25 | 1999-01-01T00:00:01.25 | ZEIT_WARTEN | 915148801.25 |
Dies lässt sich richtig entschlüsseln, wenn man auf die Zustandsvariable für die Schaltsekunde achtet, die eindeutig anzeigt, ob der Schaltvorgang bereits durchgeführt wurde. Die Änderung der Zustandsvariablen ist synchron mit dem Schaltvorgang. ⓘ
Eine ähnliche Situation ergibt sich bei einer negativen Schaltsekunde, bei der die übersprungene Sekunde etwas zu spät kommt. Kurzzeitig zeigt das System eine nominell unmögliche Zeitzahl an, was aber durch den TIME_DEL-Zustand erkannt und korrigiert werden kann. ⓘ
In dieser Art von System verstößt die Unix-Zeitnummer bei beiden Arten von Schaltsekunden gegen POSIX. Das Sammeln der Schaltsekunden-Zustandsvariable zusammen mit der Zeitnummer ermöglicht eine eindeutige Dekodierung, so dass auf Wunsch die korrekte POSIX-Zeitnummer generiert werden kann oder die vollständige UTC-Zeit in einem geeigneteren Format gespeichert werden kann. ⓘ
Die Dekodierlogik, die erforderlich ist, um mit dieser Art von Unix-Uhr zurechtzukommen, würde auch eine hypothetische POSIX-konforme Uhr, die dieselbe Schnittstelle verwendet, korrekt dekodieren. Dies würde dadurch erreicht, dass während der gesamten Dauer einer eingefügten Schaltsekunde der Zustand TIME_INS und anschließend während der gesamten Dauer der folgenden Sekunde der Zustand TIME_WAIT angezeigt wird, während die Sekundenzählung wiederholt wird. Dies erfordert eine synchrone Behandlung von Schaltsekunden. Dies ist wahrscheinlich der beste Weg, die UTC-Zeit in Form einer Unix-Uhr über eine Unix-Schnittstelle auszudrücken, wenn die zugrunde liegende Uhr grundsätzlich nicht durch Schaltsekunden beeinträchtigt wird. ⓘ
TAI-basierte Variante
Eine andere, sehr viel seltenere, nicht konforme Variante der Unix-Zeithaltung ist die Kodierung von TAI anstelle von UTC; einige Linux-Systeme sind auf diese Weise konfiguriert. Da TAI keine Schaltsekunden kennt und jeder TAI-Tag genau 86400 Sekunden lang ist, ist diese Kodierung eigentlich eine rein lineare Zählung der seit 1970-01-01T00:00:10 TAI verstrichenen Sekunden. Das macht die Zeitintervallarithmetik sehr viel einfacher. Zeitwerte aus diesen Systemen weisen nicht die Mehrdeutigkeit auf, die streng konforme POSIX-Systeme oder NTP-gesteuerte Systeme haben. ⓘ
In diesen Systemen ist es notwendig, eine Tabelle mit Schaltsekunden zu konsultieren, um korrekt zwischen UTC und der Pseudo-Unix-Zeitdarstellung zu konvertieren. Dies ähnelt der Art und Weise, wie Zeitzonentabellen für die Umrechnung in und aus der bürgerlichen Zeit konsultiert werden müssen; die IANA-Zeitzonendatenbank enthält Schaltsekundeninformationen, und der aus derselben Quelle verfügbare Beispielcode verwendet diese Informationen zur Umrechnung zwischen TAI-basierten Zeitstempeln und der Ortszeit. Die Umrechnung stößt auch auf Definitionsprobleme, die vor der Einführung der aktuellen Form von UTC im Jahr 1972 auftraten (siehe Abschnitt UTC-Basis unten). ⓘ
Dieses TAI-basierte System ist trotz seiner oberflächlichen Ähnlichkeit nicht die Unix-Zeit. Es kodiert Zeiten mit Werten, die sich um mehrere Sekunden von den POSIX-Zeitwerten unterscheiden. Eine Version dieses Systems, bei der die Epoche für die TAI-basierte Zeit 1970-01-01T00:00:00 TAI und nicht 1970-01-01T00:00:10 TAI war, wurde zur Aufnahme in ISO C's time.hvorgeschlagen, aber nur der UTC-Teil wurde 2011 akzeptiert. A tai_clock existiert jedoch in C++20. ⓘ
Bei einigen Unix-ähnlichen Systemen lässt sich mittels nachstehendem Befehl eine Unixzeit in die äquivalente UTC-Zeit umrechnen (das Verhalten von date aus dem Beispiel ist nicht Bestandteil des POSIX-Standards). ⓘ
date -u -d @UNIXTIME <span title="Aus: Deutsche Wikipedia, Abschnitt "Unix-Befehle"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Unix-Befehle <span style="color:#dddddd">ⓘ</span>]</span>Beispiel:
date -u -d @1234567890
Fr 13. Feb 23:31:30 UTC 2009 <span title="Aus: Deutsche Wikipedia, Abschnitt "Unix-Befehle"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Unix-Befehle <span style="color:#dddddd">ⓘ</span>]</span>Umgekehrt lässt sich die aktuelle Anzahl der vergangenen Sekunden seit dem 1. Januar 1970 auf einigen Unix-/Linux-Systemen mittels
date +%sanzeigen (das Verhalten von date ist auch hier nicht Bestandteil des POSIX-Standards). ⓘ
Darstellung der Zahl
Eine Unix-Zeitnummer kann in jeder Form dargestellt werden, die Zahlen darstellen kann. In einigen Anwendungen wird die Zahl einfach textuell als eine Kette von Dezimalziffern dargestellt, was nur triviale zusätzliche Probleme aufwirft. Bestimmte binäre Darstellungen von Unix-Zeiten sind jedoch von besonderer Bedeutung. ⓘ
Der Unix-Datentyp time_t, der einen Zeitpunkt repräsentiert, ist auf vielen Plattformen eine vorzeichenbehaftete Ganzzahl, die traditionell aus 32 Bits besteht (siehe jedoch unten) und die Unix-Zeitnummer direkt kodiert, wie im vorangegangenen Abschnitt beschrieben. 32 Bits bedeuten, dass es einen Bereich von insgesamt 136 Jahren abdeckt. Das kleinste darstellbare Datum ist Freitag 1901-12-13, das größte darstellbare Datum ist Dienstag 2038-01-19. Eine Sekunde nach 03:14:07 UTC 2038-01-19 wird diese Darstellung überlaufen, was als das Jahr 2038 Problem bekannt ist. ⓘ
In einigen neueren Betriebssystemen ist time_t auf 64 Bit erweitert worden. Dies erweitert die darstellbaren Zeiten um etwa 292 Milliarden Jahre in beide Richtungen, was mehr als das Zwanzigfache des derzeitigen Alters des Universums pro Richtung ist. ⓘ
Ursprünglich gab es eine Kontroverse darüber, ob die Unix time_t mit oder ohne Vorzeichen sein sollte. Wäre sie vorzeichenlos, würde sich ihre Reichweite in der Zukunft verdoppeln, wodurch der 32-Bit-Überlauf (um 68 Jahre) verschoben würde. Allerdings wäre sie dann nicht in der Lage, Zeiten vor der Epoche darzustellen. Der Konsens ist, dass time_t vorzeichenbehaftet sein soll, und dies ist die übliche Praxis. Die Software-Entwicklungsplattform für Version 6 des QNX-Betriebssystems hat einen vorzeichenlosen 32-Bit time_t, obwohl ältere Versionen einen vorzeichenbehafteten Typ verwenden. ⓘ
Die POSIX- und Open Group Unix-Spezifikationen enthalten die C-Standardbibliothek, die die in der Header-Datei <time.h> definierten Zeittypen und -funktionen enthält. Der ISO-C-Standard legt fest, dass time_t ein arithmetischer Typ sein muss, schreibt aber keinen bestimmten Typ oder eine bestimmte Kodierung vor. POSIX verlangt, dass time_t ein Integer-Typ ist, schreibt aber nicht vor, dass er vorzeichenbehaftet oder vorzeichenlos sein muss. ⓘ
Unix hat keine Tradition, nicht-ganzzahlige Unix-Zeitzahlen direkt als binäre Brüche darzustellen. Stattdessen werden Zeiten mit einer Genauigkeit von weniger als einer Sekunde durch zusammengesetzte Datentypen dargestellt, die aus zwei Ganzzahlen bestehen, wobei die erste ein time_t (der ganzzahlige Teil der Unix-Zeit) und die zweite der gebrochene Teil der Zeitzahl in Millionsteln (in struct timeval) oder Milliardsteln (in struct timespec) ist. Diese Strukturen bieten ein dezimal-basiertes Festkomma-Datenformat, das für einige Anwendungen nützlich und für andere trivial zu konvertieren ist. ⓘ
UTC-Basis
Die heutige Form der UTC mit Schaltsekunden ist erst seit dem 1. Januar 1972 definiert. Davor gab es seit dem 1. Januar 1961 eine ältere Form der UTC, bei der es nicht nur gelegentlich Zeitschritte gab, die nicht ganzzahlig waren, sondern bei der auch die UTC-Sekunde etwas länger war als die SI-Sekunde und sich periodisch änderte, um die Erdrotation kontinuierlich anzugleichen. Vor 1961 gab es keine UTC, und vor 1958 gab es keine weit verbreitete atomare Zeitmessung; in diesen Epochen wurde anstelle einer atomaren Zeitskala eine Annäherung an die GMT (die direkt auf der Erdrotation basiert) verwendet. ⓘ
Die genaue Definition der Unix-Zeit als eine Kodierung der UTC ist nur dann unumstritten, wenn sie auf die heutige Form der UTC angewendet wird. Die Unix-Epoche, die dem Beginn dieser Form von UTC vorausging, hat keinen Einfluss auf die Verwendung in dieser Ära: Die Anzahl der Tage zwischen dem 1. Januar 1970 (der Unix-Epoche) und dem 1. Januar 1972 (dem Beginn von UTC) steht nicht in Frage, und die Anzahl der Tage ist alles, was für die Unix-Zeit von Bedeutung ist. ⓘ
Die Bedeutung von Unix-Zeitwerten unter +63072000 (d. h. vor dem 1. Januar 1972) ist nicht genau definiert. Die Grundlage solcher Unix-Zeiten ist am besten als eine nicht näher spezifizierte Annäherung an die UTC zu verstehen. Die Uhren der damaligen Computer waren selten genau genug eingestellt, um aussagekräftige Zeitstempel im Sekundentakt zu liefern. Die Unix-Zeit eignet sich nicht für die Darstellung von Zeiten vor 1972 in Anwendungen, die eine Genauigkeit im Sekundenbereich erfordern; solche Anwendungen müssen zumindest festlegen, welche Form von UT oder GMT sie verwenden. ⓘ
Ab 2009 wird die Möglichkeit in Betracht gezogen, die Verwendung von Schaltsekunden in der zivilen Zeitrechnung zu beenden. Eine wahrscheinliche Möglichkeit, diese Änderung durchzuführen, ist die Definition einer neuen Zeitskala, der so genannten Internationalen Zeit, die anfangs mit der UTC übereinstimmt, danach aber keine Schaltsekunden mehr hat und somit einen konstanten Abstand zur TAI aufweist. Wenn dies geschieht, ist es wahrscheinlich, dass die Unix-Zeit in Zukunft anhand dieser neuen Zeitskala anstelle von UTC definiert wird. Die Ungewissheit darüber, ob dies der Fall sein wird, macht die künftige Unix-Zeit nicht weniger vorhersehbar als sie es ohnehin schon ist: Wenn UTC einfach keine weiteren Schaltsekunden hätte, wäre das Ergebnis dasselbe. ⓘ
Geschichte
Die frühesten Versionen der Unix-Zeit hatten eine 32-Bit-Ganzzahl, die mit einer Rate von 60 Hz inkrementiert wurde, was der Rate der Systemuhr auf der Hardware der frühen Unix-Systeme entsprach. Der Wert 60 Hz erscheint daher noch immer in einigen Software-Schnittstellen. Auch die Epoche unterschied sich vom aktuellen Wert. Die erste Ausgabe des Unix Programmer's Manual vom 3. November 1971 definiert die Unix-Zeit als "die Zeit seit 00:00:00, 1. Januar 1971, gemessen in Sechzigstel einer Sekunde". ⓘ
Das Benutzerhandbuch kommentiert auch, dass "der chronologisch denkende Benutzer feststellen wird, dass 2**32 Sechzigstel einer Sekunde nur etwa 2,5 Jahre sind". Wegen dieser begrenzten Spanne wurde die Epoche mehrmals neu definiert, bevor die Rate auf 1 Hz geändert und die Epoche auf den heutigen Wert vom 1. Januar 1970 00:00:00 UTC gesetzt wurde. Daraus ergab sich eine Spanne von etwa 136 Jahren, die Hälfte davon vor 1970 und die Hälfte danach. ⓘ
Wie aus der oben zitierten Definition hervorgeht, war die Unix-Zeitskala ursprünglich als eine einfache lineare Darstellung der seit einer Epoche verstrichenen Zeit gedacht. Die Details von Zeitskalen wurden jedoch nicht berücksichtigt, und es wurde implizit davon ausgegangen, dass bereits eine einfache lineare Zeitskala vorhanden und vereinbart war. In der Definition der ersten Auflage des Handbuchs wird nicht einmal angegeben, welche Zeitzone verwendet wird. Mehrere spätere Probleme, einschließlich der Komplexität der gegenwärtigen Definition, resultieren daraus, dass die Unix-Zeit nicht von Anfang an vollständig definiert wurde, sondern sich erst nach und nach durch den Gebrauch herausbildete. ⓘ
Als POSIX.1 geschrieben wurde, stellte sich die Frage, wie time_t angesichts der Schaltsekunden genau definiert werden sollte. Das POSIX-Komitee überlegte, ob die Unix-Zeit, wie beabsichtigt, eine lineare Zählung der Sekunden seit der Epoche bleiben sollte, auf Kosten der Komplexität bei der Umrechnung in die bürgerliche Zeit, oder eine Darstellung der bürgerlichen Zeit, auf Kosten der Inkonsistenz bei Schaltsekunden. Die Computeruhren dieser Zeit waren nicht genau genug eingestellt, um einen Präzedenzfall zu schaffen, weder für die eine noch für die andere Seite. ⓘ
Das POSIX-Komitee ließ sich von Argumenten gegen die Komplexität der Bibliotheksfunktionen leiten und definierte die Unix-Zeit auf einfache Weise anhand der Elemente der UTC-Zeit. Diese Definition war so einfach, dass sie nicht einmal die gesamte Schaltjahresregel des gregorianischen Kalenders umfasste und das Jahr 2100 zu einem Schaltjahr machen würde. ⓘ
In der POSIX.1-Ausgabe von 2001 wurde die fehlerhafte Schaltjahresregel in der Definition der Unix-Zeit korrigiert, aber die wesentliche Definition der Unix-Zeit als Kodierung von UTC und nicht als lineare Zeitskala beibehalten. Seit Mitte der 1990er Jahre werden Computeruhren routinemäßig mit ausreichender Genauigkeit eingestellt, so dass dies von Bedeutung ist, und sie werden in der Regel mit der UTC-basierten Definition der Unix-Zeit eingestellt. Dies hat zu einer erheblichen Komplexität in Unix-Implementierungen und im Network Time Protocol geführt, um Schritte in der Unix-Zeitnummer auszuführen, wenn Schaltsekunden auftreten. ⓘ
Bemerkenswerte Ereignisse in der Unix-Zeit
Unix-Enthusiasten veranstalten seit jeher "time_t parties" (ausgesprochen "time tea parties"), um signifikante Werte der Unix-Zeitnummer zu feiern. Diese sind direkt vergleichbar mit den Neujahrsfeiern, die in vielen Kalendern zum Jahreswechsel stattfinden. Mit der Verbreitung der Unix-Zeit hat sich auch die Praxis der Feier von Meilensteinen verbreitet. Normalerweise werden Zeitwerte gefeiert, die runde Dezimalzahlen sind, entsprechend der Unix-Konvention, time_t-Werte in Dezimalzahlen zu betrachten. In einigen Gruppen werden auch runde Binärzahlen gefeiert, wie z. B. +230, das am Samstag, den 10. Januar 2004 um 13:37:04 UTC eintrat. ⓘ
Die Ereignisse, die damit gefeiert werden, werden in der Regel als "N Sekunden seit der Unix-Epoche" beschrieben, aber das ist ungenau; wie oben beschrieben, ist die Anzahl der seit der Unix-Epoche verstrichenen Sekunden aufgrund der Behandlung von Schaltsekunden in der Unix-Zeit etwas größer als die Unix-Zeitzahl für Zeiten nach der Epoche. ⓘ
- Um 18:36:57 UTC am Mittwoch, dem 17. Oktober 1973, erschien zum ersten Mal das Datum im ISO 8601-Format (1973-10-17) innerhalb der Ziffern der Unix-Zeit (119731017).
- Am Sonntag, den 9. September 2001 um 01:46:40 UTC wurde das Unix Billennium (Unix-Zeitnummer 1000000000) gefeiert. Der Name billennium ist ein Portmanteau aus billion und millennium. Bei einigen Programmen, die Zeitstempel in einer Textdarstellung speicherten, kam es zu Sortierfehlern, da bei einer Textsortierung Zeiten nach dem Umsatz, beginnend mit einer 1, fälschlicherweise vor früheren Zeiten, beginnend mit einer 9, sortiert wurden. Zu den betroffenen Programmen gehörten der beliebte Usenet-Reader KNode und der E-Mail-Client KMail, der Teil der KDE-Desktop-Umgebung ist. Solche Fehler waren im Allgemeinen kosmetischer Natur und wurden schnell behoben, sobald die Probleme offensichtlich wurden. Das Problem betraf auch viele Filtrix-Dokumentenformatfilter, die mit Linux-Versionen von WordPerfect geliefert wurden; ein Patch wurde von der Benutzergemeinschaft erstellt, um dieses Problem zu lösen, da Corel diese Version des Programms nicht mehr verkauft oder unterstützt.
- Um 23:31:30 UTC am Freitag, 13. Februar 2009, erreichte die Dezimaldarstellung der Unix-Zeit 1234567890 Sekunden. Google feierte dies mit einem Google-Doodle. Auf der ganzen Welt wurden in verschiedenen technischen Subkulturen Partys und andere Feiern zur 1234567890sten Sekunde veranstaltet.
- Um 03:33:20 UTC am Mittwoch, 18. Mai 2033, wird der Unix-Zeitwert 2000000000 Sekunden betragen.
- Um 09:06:49 UTC am Freitag, 16. Juni 2034, entspricht der Unix-Zeitwert dem aktuellen Jahr, Monat, Datum und der aktuellen Stunde (2034061609).
- Um 06:28:16 UTC am Donnerstag, 7. Februar 2036, wird das Network Time Protocol zur nächsten Epoche übergehen, da der in NTP verwendete 32-Bit-Zeitstempelwert (ohne Vorzeichen, aber basierend auf dem 1. Januar 1900) überläuft. Dieses Datum liegt nahe am folgenden Datum, da die 136-Jahres-Spanne einer 32-Bit-Ganzzahl von Sekunden fast doppelt so groß ist wie der 70-Jahres-Versatz zwischen den beiden Epochen.
- Um 03:14:08 UTC am Dienstag, den 19. Januar 2038, werden 32-Bit-Versionen des Unix-Zeitstempels nicht mehr funktionieren, da er den größten Wert, der in einer vorzeichenbehafteten 32-Bit-Zahl gespeichert werden kann (7FFFFFFF16 oder 2147483647), überschreiten wird. Vor diesem Zeitpunkt muss Software, die 32-Bit-Zeitstempel verwendet, eine neue Konvention für Zeitstempel annehmen, und Dateiformate, die 32-Bit-Zeitstempel verwenden, müssen geändert werden, um größere Zeitstempel oder eine andere Epoche zu unterstützen. Bleibt der Zeitstempel unverändert, wird die nächste Sekunde fälschlicherweise als 20:45:52 Freitag, 13. Dezember 1901 UTC interpretiert. Dies wird als das Jahr 2038-Problem bezeichnet.
- Um 05:20:00 UTC am Samstag, den 24. Januar 2065, wird der Unix-Zeitwert 3000000000 Sekunden betragen.
- Um 06:28:15 UTC am Sonntag, dem 7. Februar 2106, wird die Unix-Zeit FFFFFFFF16 oder 4294967295 Sekunden erreichen, was für Systeme, die die Zeit in 32-Bit-Ganzzahlen ohne Vorzeichen speichern, das maximal erreichbare Ergebnis ist. Bei einigen dieser Systeme wird die nächste Sekunde fälschlicherweise als 00:00:00 Donnerstag, 1. Januar 1970 UTC interpretiert. Bei anderen Systemen kann ein Überlauffehler mit unvorhersehbarem Ergebnis auftreten.
- Um 15:30:08 UTC am Sonntag, den 4. Dezember 292277026596, wird die Unix-Zeit den größten Wert, der in einer vorzeichenbehafteten 64-Bit-Zahl gespeichert werden kann, überlaufen. Diese Zeitspanne entspricht fast dem 22-fachen des geschätzten aktuellen Alters des Universums, das 1,37×1010 (13,7 Milliarden) Jahre beträgt. ⓘ
In der Literatur und in der Kalendarik
Vernor Vinges Roman A Deepness in the Sky beschreibt eine raumfahrende Handelszivilisation Tausende von Jahren in der Zukunft, die noch die Unix-Epoche verwendet. Der "Programmierer-Archäologe", der dafür zuständig ist, brauchbaren Code in ausgereiften Computersystemen zu finden und zu pflegen, glaubt zunächst, dass sich die Epoche auf den Zeitpunkt bezieht, an dem der erste Mensch den Mond betrat, stellt dann aber fest, dass es sich um "die 0-Sekunde eines der ersten Computer-Betriebssysteme der Menschheit" handelt. ⓘ
Eigenschaften
Umrechnung
Die Umrechnung in eine menschenlesbare Form, einschließlich der Anwendung von Zeitzonen, Sommerzeit und Schaltjahren werden dann von zusätzlichen Funktionen der Standardbibliothek übernommen. Die Darstellung des Datums als Sekunden seit der Unix-Epoche wird häufig verwendet, weil sie für Computerprogramme viel leichter zu verarbeiten ist als das „menschliche“ Datumsformat. Es lassen sich mit diesen Werten leicht Zeiträume als Differenzen von Sekunden berechnen. Sommer- oder Winterzeit, Zeitzonen und Schaltsekunden spielen dann keine Rolle mehr. Aus diesem Grund wird dieser Wert auch gerne als Zeitstempel verwendet. In praktisch allen Server-Anwendungen spielt der Zeitstempel eine tragende Rolle, so etwa im Umfeld von PHP- oder MySQL-Applikationen bei der Unterscheidung und Generierung zeitbezogener Datenbank-Einträge. Die vordefinierten PHP-Funktionen date() und mktime() ermöglichen hier beispielsweise durch das Einsetzen passender Funktionsargumente die einfache Konvertierung eines Zeitstempels in ein menschenlesbares Datumsformat und umgekehrt. ⓘ
Schaltsekunden
Schaltsekunden werden in der Unixzeit nicht mitgezählt, da sie nicht regelmäßig auftreten, sondern je nach schwankender Erdrotation nur sechs Monate vor ihrer Einfügung angekündigt werden. Alle Tage sind in Unixzeit genau 24 × 3600 Sekunden lang, Zeitdifferenzen in Unixzeit, die über eine Schaltsekunde hinweggehen, sind daher um diese Sekunde zu kurz. ⓘ
In den letzten Jahren gab es mehrere Versuche, im Rahmen der POSIX-Standardisierung eine Darstellung der Schaltsekunde zur POSIX-Unix-Zeitdefinition hinzuzufügen. Die Diskussionen zu diesem Thema führten jedoch bislang nicht zu einem allgemein akzeptierten Ergebnis. ⓘ
Vergleich
Für die menschliche Anwendung sind auf Abschnitte herunter gebrochenen Zeiten, etwa Anzahl Jahre, Monate, Tage, Stunde mit zusätzlichen Angaben für Zeitzone und Sommerzeit übersichtlicher. Soweit eine alltägliche Zeit ohne Angabe von Sommerzeit und Zeitzone erfolgt, bleibt sie für eine computertechnische Verarbeitung allerdings noch unvollständig. Die gebrochene Darstellung macht Berechnungen in jedem Fall aufwändiger. ⓘ
Unix bietet eine Konvertierung der Unixzeit in eine gebrochene Darstellung mittels localtime()an. Sommerzeit und Zeitzone werden von dieser Funktion, für den Anwender meist unsichtbar, aus administrativen Einstellungen des Systems bezogen – deshalb local-time. ⓘ
In den DOS-Systemen war die gebrochene Zeit, aber ohne Zeitzonenangabe das Standardformat und wird auf FAT-Dateisystemen für Zeitstempel der Dateien in einer kompakten Darstellung gespeichert. ⓘ
Eine Zeitangabe kann auch als Gleitkommazahl gespeichert werden. Dabei können auch sehr weit entfernte Zeitangaben gespeichert werden, teils Millionen Jahre entfernt, dann aber mit verminderter Zeitgenauigkeit. Eine Auflösung von unter einer Sekunde ist z. B. mit einem Double-Wert für die nächsten 140 Millionen Jahre möglich. ⓘ
Besondere Werte
Unix-Enthusiasten haben es sich zum Brauch gemacht, zu bestimmten Werten der Unixzeit sogenannte „time_t-Partys“ – ähnliche den Neujahrsfeiern zum Jahreswechsel – zu veranstalten. Üblicherweise werden runde Dezimal-Werte, wie 1.000.000.000 oder 2.000.000.000 gefeiert. Unter manchen Benutzern werden allerdings auch runde Binär-Werte gefeiert, beispielsweise +230 (1.073.741.824), welcher auf den 10. Jan. 2004 13:37:04 UTC fiel. Am 13. Feb. 2009 um 23:31:30 UTC (14. Feb. 2009 um 00:31:30 CET) erreichte die Unixzeit den Wert 1234567890. Heise Online erwähnte dieses Ereignis in seinem Newsticker. ⓘ
Diese Zeitpunkte werden üblicherweise als „n Sekunden seit der Unix-Epoche“ gefeiert. Durch die Einführung von Schaltsekunden ist diese Bezeichnung allerdings nicht ganz korrekt. ⓘ
| Wert | Zeitpunkt (UTC) ⓘ | ||
|---|---|---|---|
| arithm. | dezimal | hexadez. | |
| −231 | −2 147 483 648 | 80 00 00 00 | 13. Dez. 1901 20:45:52 |
| −230 | −1 073 741 824 | B0 00 00 00 | 23. Dez. 1935 10:22:56 |
| −1 000 000 000 | C4 65 36 00 | 24. April 1938 22:13:20 | |
| −229 | −536 870 912 | E0 00 00 00 | 27. Dez. 1952 05:11:28 |
| −228 | −268 435 456 | F0 00 00 00 | 30. Juni 1961 02:35:44 |
| 0 | 00 00 00 00 | 1. Jan. 1970 00:00:00 | |
| 216 | 65 536 | 00 01 00 00 | 1. Jan. 1970 18:12:16 |
| 224 | 16 777 216 | 01 00 00 00 | 14. Juli 1970 04:20:16 |
| 100 000 000 | 05 F5 E1 00 | 3. März 1973 09:46:40 | |
| 228 | 268 435 456 | 10 00 00 00 | 4. Juli 1978 21:24:16 |
| 500 000 000 | 1D CD 65 00 | 5. Nov. 1985 00:53:20 | |
| 229 | 536 870 912 | 20 00 00 00 | 5. Jan. 1987 18:48:32 |
| 805 306 368 | 30 00 00 00 | 9. Juli 1995 16:12:48 | |
| 1 000 000 000 | 3B 9A CA 00 | 9. Sep. 2001 01:46:40 | |
| 230 | 1 073 741 824 | 40 00 00 00 | 10. Jan. 2004 13:37:04 |
| 1 111 111 111 | 42 3A 35 C7 | 18. März 2005 01:58:31 | |
| 1 234 567 890 | 49 96 02 D2 | 13. Feb. 2009 23:31:30 | |
| 1 300 000 000 | 4D 7C 6D 00 | 13. März 2011 07:06:40 | |
| 1 342 177 280 | 50 00 00 00 | 13. Juli 2012 11:01:20 | |
| 1 400 000 000 | 53 72 4E 00 | 13. Mai 2014 16:53:20 | |
| 1 500 000 000 | 59 68 2F 00 | 14. Juli 2017 02:40:00 | |
| 1 600 000 000 | 5F 5E 10 00 | 13. Sep. 2020 12:26:40 | |
| 1,5 · 230 | 1 610 612 736 | 60 00 00 00 | 14. Jan. 2021 08:25:36 |
| 1 700 000 000 | 65 53 F1 00 | 14. Nov. 2023 22:13:20 | |
| 1 800 000 000 | 6B 49 D2 00 | 15. Jan. 2027 08:00:00 | |
| 1 879 048 192 | 70 00 00 00 | 18. Juli 2029 05:49:52 | |
| 1 900 000 000 | 71 3F B3 00 | 17. März 2030 17:46:40 | |
| 2 000 000 000 | 77 35 94 00 | 18. Mai 2033 03:33:20 | |
| 2 100 000 000 | 7D 2B 75 00 | 18. Juli 2036 13:20:00 | |
| 231−1 | 2 147 483 647 | 7F FF FF FF | 19. Jan. 2038 03:14:07 |
| Bei Verwendung des vorzeichenlosen (unsigned-) 32-bit-Typ | |||
| 232−1 | 4 294 967 295 | FF FF FF FF | 7. Feb. 2106 06:28:15 |
Beispiel-Implementierung
Möchte man die Unixzeit zu einem gegebenen Zeitpunkt berechnen, lässt sich das über folgenden Rechenweg bewerkstelligen. Die Unixzeit kennt keine Zeitzonen und nutzt als Eingabe eine von Zeitzonen bereinigte Zeit. Schaltsekunden werden mangels Vorhersagbarkeit weder für die Vergangenheit noch für die Zukunft berücksichtigt. ⓘ
Achtung: Der folgende Quelltext ist in der Programmiersprache C verfasst und arbeitet mit maschinenabhängigen Datentypen. Das Jahr-2038-Problem tritt bei diesem Programm jedoch nicht auf, da der verwendete Datentyp „long long“ mindestens 64 Bits besitzt. Wie jeder Beispielquelltext dient er allein der Illustration und sollte ohne Überprüfung nicht in den Praxiseinsatz übernommen werden. ⓘ
/** Konvertiert gegliederte UTC-Angaben in Unix-Zeit.
* Parameter und ihre Werte-Bereiche:
* - jahr [1970..2038]
* - monat [1..12]
* - tag [1..31]
* - stunde [0..23]
* - minute [0..59]
* - sekunde [0..59]
*/
long long unixzeit(int jahr, int monat, int tag,
int stunde, int minute, int sekunde)
{
const short tage_seit_jahresanfang[12] = /* Anzahl der Tage seit Jahresanfang ohne Tage des aktuellen Monats und ohne Schalttag */
{0,31,59,90,120,151,181,212,243,273,304,334}; <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
int schaltjahre = ((jahr-1)-1968)/4 /* Anzahl der Schaltjahre seit 1970 (ohne das evtl. laufende Schaltjahr) */
- ((jahr-1)-1900)/100
+ ((jahr-1)-1600)/400; <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
long long tage_seit_1970 = (jahr-1970)*365 + schaltjahre
+ tage_seit_jahresanfang[monat-1] + tag-1; <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
if ( (monat>2) && (jahr%4==0 && (jahr%100!=0 || jahr%400==0)) )
tage_seit_1970 += 1; /* +Schalttag, wenn jahr Schaltjahr ist */ <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
return sekunde + 60 * ( minute + 60 * (stunde + 24*tage_seit_1970) );
}Eine Umrechnung von einer gegebenen Unixzeit in unsere gewöhnliche Datums- und Zeitdarstellung ist mit folgender Funktion möglich.
void UnixzeitNachDatumZeit(unsigned long int unixtime,
int *pJahr, int *pMonat, int *pTag,
int *pStunde, int *pMinute, int *pSekunde)
{
const unsigned long int SEKUNDEN_PRO_TAG = 86400ul; /* 24* 60 * 60 */
const unsigned long int TAGE_IM_GEMEINJAHR = 365ul; /* kein Schaltjahr */
const unsigned long int TAGE_IN_4_JAHREN = 1461ul; /* 4*365 + 1 */
const unsigned long int TAGE_IN_100_JAHREN = 36524ul; /* 100*365 + 25 - 1 */
const unsigned long int TAGE_IN_400_JAHREN = 146097ul; /* 400*365 + 100 - 4 + 1 */
const unsigned long int TAGN_AD_1970_01_01 = 719468ul; /* Tagnummer bezogen auf den 1. Maerz des Jahres "Null" */ <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
unsigned long int TagN = TAGN_AD_1970_01_01 + unixtime/SEKUNDEN_PRO_TAG;
unsigned long int Sekunden_seit_Mitternacht = unixtime%SEKUNDEN_PRO_TAG;
unsigned long int temp; <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
/* Schaltjahrregel des Gregorianischen Kalenders:
Jedes durch 100 teilbare Jahr ist kein Schaltjahr, es sei denn, es ist durch 400 teilbar. */
temp = 4 * (TagN + TAGE_IN_100_JAHREN + 1) / TAGE_IN_400_JAHREN - 1;
*pJahr = 100 * temp;
TagN -= TAGE_IN_100_JAHREN * temp + temp / 4; <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
/* Schaltjahrregel des Julianischen Kalenders:
Jedes durch 4 teilbare Jahr ist ein Schaltjahr. */
temp = 4 * (TagN + TAGE_IM_GEMEINJAHR + 1) / TAGE_IN_4_JAHREN - 1;
*pJahr += temp;
TagN -= TAGE_IM_GEMEINJAHR * temp + temp / 4; <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
/* TagN enthaelt jetzt nur noch die Tage des errechneten Jahres bezogen auf den 1. Maerz. */
*pMonat = (5 * TagN + 2) / 153;
*pTag = TagN - (*pMonat * 153 + 2) / 5 + 1;
/* 153 = 31+30+31+30+31 Tage fuer die 5 Monate von Maerz bis Juli
153 = 31+30+31+30+31 Tage fuer die 5 Monate von August bis Dezember
31+28 Tage fuer Januar und Februar (siehe unten)
+2: Justierung der Rundung
+1: Der erste Tag im Monat ist 1 (und nicht 0).
*/ <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
*pMonat += 3; /* vom Jahr, das am 1. Maerz beginnt auf unser normales Jahr umrechnen: */
if (*pMonat > 12)
{ /* Monate 13 und 14 entsprechen 1 (Januar) und 2 (Februar) des naechsten Jahres */
*pMonat -= 12;
++*pJahr;
} <span title="Aus: Deutsche Wikipedia, Abschnitt "Beispiel-Implementierung"" class="plainlinks">[https://de.wikipedia.org/wiki/Unixzeit#Beispiel-Implementierung <span style="color:#dddddd">ⓘ</span>]</span>
*pStunde = Sekunden_seit_Mitternacht / 3600;
*pMinute = Sekunden_seit_Mitternacht % 3600 / 60;
*pSekunde = Sekunden_seit_Mitternacht % 60;
}Diese Funktion erwartet als Eingangsparameter eine vorzeichenlose Ganzzahl („unsigned long int“). Nach dem C-Standard sind das mindestens 32 Bit. Die Funktion liefert somit korrekte Ergebnisse bis mindestens zum Januar 2106. ⓘ