Ein Unix-Zeitstempel wird in ein lesbares Datum umgewandelt und zurück. Die Einheit wird an der Größenordnung erkannt, sodass Sekunden, Millisekunden, Mikrosekunden und Nanosekunden alle akzeptiert werden; die angenommene Einheit wird neben dem Ergebnis genannt.
Ein Unix-Zeitstempel zählt ab Mitternacht UTC am 1. Januar 1970. Das Problem beim Lesen ist, dass dieselben Ziffern je nach Einheit verschiedene Momente bedeuten: 1700000000 ist in Sekunden der November 2023 und in Millisekunden der Januar 1970. Erkannt wird an der Größenordnung statt an der Ziffernzahl, denn eine zehnstellige Zahl ist nicht zuverlässig eine Sekundenangabe, und ein negativer Zeitstempel — ein Datum vor 1970 — hat überhaupt keine brauchbare Ziffernzahl. Weil die angenommene Einheit mit dem Ergebnis angezeigt wird, ist eine falsche Vermutung sichtbar statt still.
Zeitstempel, über die man stolpert
-
Die Einheit ist der übliche Fehler:
Sekunden und Millisekunden unterscheiden sich um den Faktor tausend, was ein aktuelles Datum zu 1970 macht oder ein plausibles in die ferne Zukunft verschiebt. Das Ergebnis nennt die angenommene Einheit.
-
Zeitstempel sind immer UTC:
Die Zahl trägt keine Zeitzone. Jede lokale Zeit, die Sie sehen, entsteht dadurch, dass Ihr Gerät seinen eigenen Versatz anwendet — derselbe Zeitstempel wird auf zwei Rechnern also unterschiedlich angezeigt.
-
Negative Werte sind gültig:
Daten vor 1970 werden durch negative Zahlen dargestellt und hier verarbeitet statt abgelehnt.
-
Schaltsekunden werden nicht abgebildet:
Die Unix-Zeit überspringt sie definitionsgemäß und ist daher keine echte Zählung verstrichener SI-Sekunden. Das ist für Präzisionszeitmessung relevant und für fast nichts sonst.
The same ten digits can mean two entirely different moments
1700000000 is a date in November 2023 read as seconds, and a date in January 1970 read as milliseconds — identical digits, two moments more than fifty years apart. The [msm_tool slug="time-converter"] exists specifically to remove that ambiguity, detecting the unit from the number's magnitude and stating which one it assumed directly alongside the converted result.
Why magnitude beats counting digits
A ten-digit number is not reliably seconds on its own, and a negative timestamp — a date before 1970 — has no useful digit count to reason from at all. Detecting the unit from how large the number actually is, rather than simply how many digits it has, is what lets seconds, milliseconds, microseconds and nanoseconds all be handled through the same input without asking which one was intended first.
Every timestamp is UTC; what you see locally is your device's doing
The number itself carries no timezone whatsoever. Any local time shown is your own device applying its own offset at display time, which is exactly why the same timestamp can appear as two different clock times to two people looking at it from different places — comparing the raw UTC values directly is the way to be certain both people are actually discussing the same moment.
Negative numbers are a normal part of the format
A negative timestamp represents a genuine moment before 1970 and is handled correctly here rather than rejected. Where a system refuses negative timestamps, that refusal is a limitation of that particular system rather than anything wrong with the timestamp itself.
Why the year 2038 shows up in timestamp discussions
Systems that store Unix time in a signed 32-bit integer run out of range in January 2038 and wrap around to a negative number, silently jumping to a date in the past instead of the future one that was actually meant. Anything using a 64-bit timestamp is unaffected for a span of time considerably longer than the universe has existed so far.