Unix-Zeit wirkt zunächst wie die einfachste mögliche Zeitdarstellung: eine Zahl zählt seit einem festgelegten Ursprung. Sie lässt sich vergleichen, sortieren und zwischen Systemen übertragen. Trotzdem entstehen regelmäßig Fehler, weil die Zahl ohne Einheit und Semantik unvollständig ist. Sekunden werden als Millisekunden gelesen, ein lokaler Kalendertag wird zum Zeitpunkt gemacht oder eine Systemuhr springt während einer Laufzeitmessung. Ein Timestamp löst viele Darstellungsfragen, aber nicht das gesamte Problem Zeit.

Die Epoch ist ein gemeinsamer Bezugspunkt

Unix-Zeit zählt nominell Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC. Ein positiver Wert beschreibt einen späteren Zeitpunkt, negative Werte können frühere Zeitpunkte darstellen. Dadurch brauchen Systeme für einen Moment keine ausgeschriebenen Jahre, Monate oder Zeitzonen zu übertragen.

Die Zahl ist besonders praktisch für Vergleiche und Speicherung. Zwei Zeitpunkte lassen sich unabhängig von ihrer späteren lokalen Anzeige ordnen. Erst die Präsentation wandelt den Wert in eine Kalenderdarstellung für eine bestimmte Zone um.

Sekunden und Millisekunden sehen beide plausibel aus

Viele Unix-APIs verwenden Sekunden, JavaScript arbeitet häufig mit Millisekunden. Andere Systeme bieten Mikro- oder Nanosekunden. Ohne Feldname oder Schema kann eine Zahl um den Faktor tausend falsch interpretiert werden und trotzdem wie ein gültiger Integer aussehen.

Verträge sollten Einheiten im Namen oder Typ sichtbar machen, etwa created_at_ms, oder einen standardisierten Textzeitstempel verwenden. Heuristiken anhand der Stellenzahl brechen bei historischen Werten und in der Zukunft.

Ein Zeitpunkt besitzt keine eigene lokale Zeitzone

Ein Instant bezeichnet denselben Moment weltweit. „14:00 in Berlin“ ist dagegen eine lokale Darstellung, die von Datum und Zeitzonenregeln abhängt. Wird ein Unix-Timestamp nach Berlin oder Tokio formatiert, ändern sich Uhrzeit und möglicherweise Kalendertag, nicht der zugrunde liegende Moment.

Für Ereignisse wie Zahlungseingang oder Logeintrag ist das ideal. Für Geburtstage, Feiertage oder „jeden Tag um 9 Uhr im Büro“ reicht ein Instant allein nicht, weil die lokale Kalenderabsicht erhalten bleiben muss.

UTC ist eine Referenz, keine Benutzeroberfläche

Server speichern Ereigniszeitpunkte häufig in UTC und vermeiden damit lokale Mehrdeutigkeit. Nutzer erwarten dennoch ihre Zone, Sprache und Kalenderkonvention. Eine Anwendung sollte deshalb den Instant kanonisch halten und erst an der Ausgabengrenze formatieren.

„Alles in UTC“ löst nicht die Planung lokaler Termine. Wird eine tägliche 9-Uhr-Erinnerung einmal in UTC umgerechnet, verschiebt sie sich nach einer Sommerzeitumstellung. Die Zone gehört zur wiederkehrenden Regel.

Schaltsekunden passen nicht sauber in das Modell

Die Rotation der Erde ist nicht vollkommen gleichmäßig. UTC wurde deshalb gelegentlich um Schaltsekunden ergänzt. Klassische Unix-Zeit behandelt diese nicht überall identisch; Betriebssysteme und Dienste können sie überspringen, wiederholen oder über ein Zeitfenster „verschmieren“.

Für gewöhnliche Geschäftsanwendungen ist die Abweichung selten entscheidend, für verteilte Messungen und präzise Ereignisreihenfolgen jedoch relevant. Ein Timestamp sollte nicht als perfekte physikalische Zeitachse missverstanden werden.

Die Systemuhr kann springen

Die Wall Clock wird durch NTP korrigiert, manuell geändert oder in virtuellen Umgebungen angepasst. Eine später gelesene Uhrzeit kann deshalb kleiner sein als die vorherige. Für Laufzeitmessungen und Timeouts ist eine monotone Uhr geeigneter, die nur vorwärts läuft.

Wall Clock beantwortet „Wann ist das Ereignis laut Kalender passiert?“. Monotonic Time beantwortet „Wie viel Zeit ist seit einem Startpunkt vergangen?“. Beide Werte erfüllen verschiedene Aufgaben und dürfen nicht beliebig ausgetauscht werden.

Präzision ist nicht dasselbe wie Genauigkeit

Ein Nanosekundenfeld kann viele Dezimalstellen enthalten, obwohl die zugrunde liegende Uhr nur Millisekunden genau oder zwischen Hosts schlecht synchronisiert ist. Zusätzliche Stellen erzeugen dann keine verlässlichere Reihenfolge.

APIs sollten nur die benötigte Präzision versprechen. Datenbanken können beim Speichern runden, und Serialisierer können Nachkommastellen verlieren. Round-Trip-Tests zeigen, welche Präzision tatsächlich erhalten bleibt.

Große Zahlen treffen auf Sprachgrenzen

Nanosekunden seit 1970 überschreiten den exakt darstellbaren Integerbereich gewöhnlicher JavaScript-Zahlen. Auch 32-Bit-Systeme hatten mit Sekundenwerten rund um das Jahr 2038 ein bekanntes Limit. Ein formal gültiges JSON kann dadurch im Client gerundet werden.

Große Werte sollten als String, BigInt-kompatible Form oder standardisierter Zeittext übertragen werden. Die Wahl muss für alle unterstützten Clients getestet sein, nicht nur für das Backend.

ISO-8601-Text ist oft leichter zu prüfen

Ein Wert wie 2026-06-06T12:30:00Z trägt Einheit und UTC-Bezug sichtbar. Ein Offset wie +02:00 beschreibt ebenfalls einen eindeutigen Moment. Text ist länger, aber in Logs und APIs für Menschen leichter zu verstehen.

Nicht jede ISO-ähnliche Zeichenfolge ist gleich eindeutig. Fehlender Offset, optionale Präzision und verschiedene Kalenderformen brauchen weiterhin ein Profil. Producer sollten eine kanonische Form ausgeben, Consumer nur dokumentierte Varianten akzeptieren.

Datenbanken unterscheiden Zeittypen

Ein „timestamp with time zone“ kann je nach Datenbank einen Instant normalisieren, während ein Typ ohne Zone nur lokale Felder speichert. Der Name allein genügt nicht; Engineverhalten, Treiber und Session-Zeitzone müssen bekannt sein.

Migrationen sollten Werte mit bekannten Zonen testen. Ein bestehender lokaler Wert lässt sich nicht korrekt in UTC verwandeln, wenn die ursprüngliche Zone verloren gegangen ist.

Reihenfolge in verteilten Systemen braucht mehr als Uhren

Zwei Hosts können trotz Synchronisierung leicht abweichen. Netzwerkverzögerung sorgt zusätzlich dafür, dass Empfangsreihenfolge und Erzeugungszeit auseinanderfallen. Für kausale oder transaktionale Ordnung sind Sequenzen, Datenbankversionen oder logische Uhren geeigneter.

Ein Timestamp bleibt wertvoll für Beobachtung und ungefähre Sortierung. Er sollte jedoch keine starke Garantie vortäuschen, die die Infrastruktur nicht liefern kann.

Ein vollständiger Zeitvertrag nennt Zweck und Einheit

Bei jedem Feld sollte klar sein, ob es einen Instant, ein lokales Datum, eine Dauer oder eine wiederkehrende Regel darstellt. Für einen Timestamp gehören Einheit, Präzision und zulässiger Bereich dazu. Für Anzeige kommt die Benutzerzone erst später hinzu.

Unix-Zeit ist ein hervorragendes Werkzeug für konkrete Momente. Ihre Einfachheit funktioniert dann am besten, wenn Systeme nicht versuchen, alle anderen Zeitkonzepte ebenfalls in dieselbe nackte Zahl zu pressen.