Negative Unix-Zeitstempel: Daten vor 1970 richtig umrechnen

Die meisten Menschen begegnen Unix-Zeit als große, stetig wachsende positive Zahl — die Art Wert, die Sie in einer Log-Zeile oder einer created_at-Spalte sehen. Es ist also eine übliche Überraschung, wenn zum ersten Mal irgendwo -1234567890 auftaucht und der Parser es entweder zu einem Datum in den 1930ern auflöst oder einen Fehler wirft. Keine der beiden Reaktionen hat wirklich damit zu tun, dass die Zahl falsch wäre. Unix-Zeit wurde als vorzeichenbehaftete Zählung ab einem festen Nullpunkt definiert, und eine vorzeichenbehaftete Zählung kann negativ werden. Dieser Ratgeber erklärt, was ein negativer Zeitstempel bedeutet, wo Sie tatsächlich darauf stoßen, und warum manche Codes an etwas scheitern, das das Format seit Anbeginn unterstützt.

Was ein negativer Zeitstempel tatsächlich bedeutet

Ein Unix-Zeitstempel ist die Anzahl Sekunden seit 00:00:00 UTC am 1. Januar 1970 — der Epoche. POSIX (IEEE Std 1003.1) definiert den zugrunde liegenden Typ time_t als vorzeichenbehaftete Ganzzahl, gezählt relativ zur Epoche, nicht aufwärts ab ihr. Relative Zählungen gehen in beide Richtungen: Ein positiver Wert ist so viele Sekunden nach der Epoche, und ein negativer Wert ist so viele Sekunden davor. Null ist keine besondere Untergrenze — sie ist schlicht der Bezugspunkt, genauso wie 0 °C ein Bezugspunkt ist und nicht die niedrigstmögliche Temperatur.

Ein negativer Zeitstempel löst sich also genau so auf, wie man es erwarten würde:

Das Muster ist in beide Richtungen linear: Jede Sekunde vor der Epoche zieht eins von der Zählung ab, genau wie jede Sekunde danach eins hinzufügt. Bei null gibt es keinen Bruch, um den man sich sorgen müsste.

Wo negative Zeitstempel tatsächlich auftauchen

Sie brauchen keine historischen Daten, um darauf zu stoßen. Die häufigsten realen Quellen sind:

Geburtsdaten und andere Aufzeichnungen vor 1970. Jedes System, das Geburtsdaten, historische Ereignisse oder Archivunterlagen als Epoch-Sekunden speichert, erzeugt für jeden vor 1970 Geborenen negative Werte — was, Stand 2026, die meisten Erwachsenen über 56 betrifft.

Standard- oder Platzhalterwerte. Manche Codebasen verwenden 0 oder eine kleine negative Zahl als Platzhalter für „nicht gesetzt“, was dann fälschlich als echtes Datum statt als Platzhalter gelesen wird — ein Fehler, der aber voraussetzt, dass negative Werte überhaupt parsebar sind, nicht dass sie ungültig wären.

Uhrenabweichung und Testfixtures. Ein Client mit einer stark falsch gehenden Systemuhr, oder ein Unit-Test, der absichtlich ein Grenzfall-Datum wählt, kann einen negativen Wert weit vor der Epoche erzeugen, ohne dass jemand überhaupt historische Daten meinte.

Warum manche Tools sie trotzdem ablehnen

Die Ablehnung ist fast immer eine Implementierungsentscheidung, keine Vorgabe der Spezifikation. Drei Muster erklären das meiste davon:

Manche ältere oder eingebettete Systeme verwendeten für time_t eine vorzeichenloseGanzzahl statt der vorzeichenbehafteten von POSIX, entweder um den künftigen Bereich zu verdoppeln, oder weil die Plattform nie Daten vor 1970 erwartete. Ein vorzeichenloser Typ hat schlicht keine Darstellung für negative Zahlen — eine Speicherentscheidung, unabhängig davon, was Unix-Zeit bedeuten darf.

Manche Formularvalidierungen oder API-Schemata fügen eine Regel wie timestamp >= 0 hinzu, weil das Feld nur „aktuelle“ Werte enthalten soll (eine Login-Zeit, eine Request-Zeit), und der Autor nie bedacht hat, dass der Typ auch für ein Geburtsdatum oder ein historisches Feld wiederverwendet würde.

Und manche Parser wurden ausschließlich gegen aktuelle, positive Werte geschrieben und getestet, sodass ein negativer Wert einen Codepfad auslöst — meist String-zu-Zahl-Parsing oder ziffernanzahlbasierte Einheitenerkennung wie „16 Ziffern bedeutet Mikrosekunden“ —, den niemand gegen ein führendes Minuszeichen geprüft hat.

Nichts davon bedeutet, dass der Zeitstempel selbst fehlerhaft ist. Kontrollieren Sie das Schema selbst, ist die Lösung, einen vorzeichenbehafteten 64-Bit-Typ zu verwenden (den ohnehin jede gängige Sprache und Datenbank standardmäßig nutzt) und die willkürliche >= 0-Beschränkung fallenzulassen, außer das Feld kann wirklich nie historisch sein.

Einen negativen Zeitstempel korrekt umrechnen

Die Rechnung ist identisch zu einem positiven Zeitstempel — mit 1000 multiplizieren, um von Sekunden zu Millisekunden zu kommen, falls der Date-Konstruktor Ihrer Sprache Millisekunden erwartet (die meisten tun das: JavaScripts Date etwa akzeptiert Millisekundenwerte über einen Bereich von rund ±8,64 × 10¹⁵, was jeden realistisch auftretenden negativen Wert komfortabel abdeckt). Der einzige praktische Unterschied ist die Einheitenerkennung nach Ziffernanzahl, wie viele Zeitstempel-Tools (auch unseres) zwischen Sekunden, Millisekunden und Mikrosekunden unterscheiden: Ein führendes Minuszeichen muss vor dem Zählen der Ziffern entfernt und anschließend auf das Ergebnis wieder angewendet werden. Korrekt gemacht, durchläuft ein negativer Zeitstempel ISO 8601 genau wie ein positiver — siehe unseren Ratgeber zu Epoche und Präzision dafür, wie die Ziffernanzahl-Erkennung selbst funktioniert.

Die Kurzfassung

Ein negativer Unix-Zeitstempel ist kein Fehlerzustand — es ist das Format, das genau wie spezifiziert funktioniert, rückwärts von einem festen Nullpunkt zählend statt vorwärts. Lehnt Ihr eigener Code negative Werte ab, ist das eine Validierungsregel, die Sie selbst hinzugefügt haben, keine Grenze des Formats. Und lehnt ein Drittanbieter-Tool sie ab, besteht die Lösung meist darin, zu einem zu wechseln, das — wie ein vorzeichenbehafteter 64-Bit-Epoch-Umrechner — tatsächlich gegen Eingaben vor 1970 getestet wurde.