Zum Inhalt springen
DevTools / Unix-Zeitstempel-Konverter

Unix-Zeitstempel-Konverter

A Unix timestamp is unambiguous and unreadable, which is a good combination for machines and a bad one for anyone reading logs at two in the morning. This converter translates in both directions, accepts seconds, milliseconds, microseconds or nanoseconds and detects which it is being given, renders the result in fourteen formats including ISO 8601, RFC 2822 and a human relative phrase, works in any of the four hundred or so timezones the browser knows about, and can tick live from the current time if you need to watch a clock.

Läuft vollständig im Browser – nichts wird hochgeladen.

Current Unix timestamp
—
Milliseconds—
Local time—

Numbers are read as epoch values; anything else goes through the browser date parser.

So funktioniert es

A Unix timestamp counts time since 00:00:00 UTC on 1 January 1970, excluding leap seconds — which means it is not strictly a count of elapsed seconds, and the difference matters only to astronomers and to anyone comparing it against a monotonic clock. It is timezone-free by construction, which is its virtue: a timestamp means the same instant everywhere, and a timezone is applied only when it is rendered. Most of the confusion around timestamps comes from forgetting that the number carries no zone information at all.

The unit is the single most common source of bugs. Unix time is conventionally seconds, but JavaScript's Date constructor and most mobile platforms use milliseconds, so a value of 1700000000 interpreted as milliseconds lands in January 1970 and one of 1700000000000 interpreted as seconds lands tens of thousands of years in the future. Both failures are immediately visible here, and the unit is detected from the magnitude of the input — a ten-digit number is seconds, a thirteen-digit number is milliseconds — with the choice overridable in either direction.

The 2038 problem is the other limit worth knowing. A signed 32-bit integer of seconds overflows on 19 January 2038, and any system storing timestamps that way — including many embedded devices, older databases and C code using time_t on 32-bit platforms — will wrap to a negative value and report a date in 1901. The fix is a 64-bit integer, which these days is universal in new code but far from universal in the field. This tool renders dates beyond 2038 correctly because it uses 64-bit arithmetic throughout.

Rendering is where timezones enter. The same instant is 09:00 in London in winter and 10:00 in summer, and the offset is not a constant — it depends on daylight saving rules that governments change with little notice. The converter uses the browser's own timezone database, which is the same data that keeps your operating system clock correct, so it reflects historical and announced rule changes rather than a hardcoded offset table. The IANA timezone names such as Europe/London or America/New_York are the correct identifiers; abbreviations like EST or CST are ambiguous and should be avoided in any system that stores or exchanges times.

Typische Anwendungsfälle

  • Read a timestamp from a database row or a log line as an actual date.
  • Generate a timestamp for a query range or a cache expiry header.
  • Check whether an API's exp or iat field refers to a time in the past.
  • Confirm what time an event happened in a colleague's timezone rather than your own.
  • Verify that a system is storing seconds rather than milliseconds before a migration.
  • Convert a date to an ISO 8601 string for a log format or a JSON field.

Zuletzt aktualisiert: 2026-10-14 — der Artikeltext wird auf Englisch angezeigt; die Oberfläche ist übersetzt.

Häufige Fragen

Should I store timestamps in seconds or milliseconds?

Be explicit rather than assuming either. Seconds is the Unix convention and what most databases and APIs use; milliseconds is what JavaScript and many mobile SDKs use. The failure mode is silent misinterpretation by a factor of a thousand, which produces a plausible-looking date in the wrong era rather than an error. Whichever you choose, put the unit in the column name or the API field name — created_at_ms is self-documenting and created_at is not.

What is the 2038 problem?

A signed 32-bit integer holding seconds since 1970 runs out on 19 January 2038 at 03:14:07 UTC, when it overflows to the most negative value and the date becomes 13 December 1901. Any system using 32-bit time_t — older C code, some embedded firmware, some legacy database schemas — is affected. The solution is to store timestamps in 64-bit integers, which is standard in new code but worth auditing for in long-lived systems, particularly in the internet of things.

Why does the same timestamp show a different time for my colleague?

Because the timestamp denotes an instant and the timezone is applied at render time. If your colleague is in a different zone, their browser renders the same instant with their own offset, and during the weeks when one location observes daylight saving and the other does not, the difference changes by an hour. This is correct behaviour: store and transmit instants, convert to local time only for display. The tool lets you select any timezone explicitly so the intended zone is unambiguous.

Does Unix time account for leap seconds?

No. Unix time is a count of seconds that have elapsed excluding leap seconds, which means it diverges from a strict count of SI seconds by the 27 leap seconds inserted since 1972. The practical consequence is that Unix time and UTC differ by a small integer, and that a system relying on Unix time will be wrong by that amount if it compares against an atomic clock rather than a calendar. For everything except precise astronomy and satellite navigation, the simplification is what makes the format useful.

Verwandte Werkzeuge