Zeitstempel umrechnen

Unix Timestamp Converter turns a timestamp into every useful spelling of the same instant, and the other way round. The unit is detected from magnitude and stated: the same integer is a moment in 1970 or in 2026 depending on whether it counts seconds or milliseconds, and a converter that guesses silently produces a date that looks plausible and is wrong by a factor of a thousand.

Nur lokal

Die Oberfläche dieses Tools ist auf Englisch.

Timestamp or date

Zone

Enter a timestamp or ISO date above, or click “Now, here” or “Try Example”.

Die folgende Anleitung ist nur auf Englisch verfügbar.

How does Unix Timestamp Converter work?

The arithmetic is trivial. Working out what the number in front of you actually represents is not, and that is where the mistakes happen.

A Unix timestamp carries no units

1757577600 is seconds since 1970 and lands on 11 September 2025. Read as milliseconds it lands on 21 January 1970. Read as microseconds, twenty-nine minutes after midnight on 1 January 1970. Nothing in the value says which, so the unit is inferred from magnitude — ten digits or fewer is seconds, eleven to thirteen is milliseconds, and so on — and the inference is shown next to the result rather than applied silently. That distinction matters: an inference you can see is a fact you can override.

Year 2038 is not hypothetical

A signed 32-bit time_t runs out at 03:14:07 UTC on 19 January 2038, when it overflows to 1901. Modern operating systems moved to 64 bits years ago, but embedded firmware, old file formats and some database columns did not, and code that stores a timestamp in an INT column has the same ceiling. It is in the examples below because it is worth testing against.

A time zone offset belongs to the instant, not the zone

London is +00:00 in January and +01:00 in July, so “Europe/London” does not identify an offset — it identifies a set of rules for deriving one from a date. The ISO output here reads the offset for your specific instant from the platform's time zone database rather than computing it, which is what makes it correct across a daylight-saving boundary. Anything that hard-codes an offset is wrong twice a year.

Unix time has no leap seconds

A Unix timestamp is defined as the number of non-leap seconds since the epoch, which means it cannot represent one. When a leap second is inserted, implementations either repeat a value or smear the extra second across a day. So the difference between two Unix timestamps is not exactly the elapsed physical time — off by 27 seconds since 1972, which matters for almost nothing and matters enormously for the few things it matters for.

ISO week numbers are not what people expect

Under ISO 8601 a week starts on Monday and week 1 is the one containing the first Thursday, so 1 January is sometimes in week 52 or 53 of the previous year. This is why a dashboard can show a week 53 that another shows as week 1, and both are right under different rules.

Input

1757577600

Resolved

unit      seconds (10 digits or fewer)
ISO       2025-09-11T08:00:00.000Z
RFC 2822  Thu, 11 Sep 2025 08:00:00 GMT
relative  last year

What options and edge cases does Unix Timestamp Converter support?

Accepted input and output
Parameter	Type	Default	Behaviour & edge cases
10 digits or fewer	seconds	detected	The classic Unix epoch unit, and what almost every API and database means by a timestamp.
11 to 13 digits	milliseconds	detected	What JavaScript's Date.now returns, and what most JSON APIs written in JavaScript emit.
14 to 16 digits	microseconds	detected	Postgres internal timestamps and Python's time.time_ns divided by a thousand.
17 or more digits	nanoseconds	detected	Go's time.UnixNano and Prometheus exposition format.
ISO 8601	date string	accepted	2026-09-11T08:00:00Z and its variants. An ISO string without a zone is read as local time by the platform, which is a genuine ambiguity in the format rather than a choice made here.
Relative	expression	accepted	`3 days ago`, `2 hours`, `now`. Month and year are approximations, because neither has a fixed length.
Time zone	IANA name	your local zone	The offset is read from the platform's database for that specific instant, so it is correct on both sides of a daylight-saving change.
ISO week	1 to 53	computed	Weeks start on Monday; week 1 contains the first Thursday. 1 January can therefore be in week 52 or 53 of the previous year.

Frequently asked questions

Why did my timestamp resolve to 1970?

You almost certainly pasted seconds into something expecting milliseconds, or the other way round. This tool detects the unit from the magnitude and tells you which it chose, so check that line first. A ten-digit number is seconds; a thirteen-digit number is milliseconds. Multiplying or dividing by a thousand is the whole fix.

Seconds or milliseconds — which should my API use?

Seconds, unless you genuinely need sub-second precision, and say which in your documentation either way. Seconds is what Unix, most databases and most languages mean by a timestamp; milliseconds is what JavaScript means. The bugs come from the boundary between them, so the useful discipline is to name the unit in the field itself: created_at_ms rather than created_at.

What actually happens in 2038?

A signed 32-bit time_t overflows at 03:14:07 UTC on 19 January 2038 and wraps to December 1901. 64-bit systems are fine and have been for years; what is not fine is embedded firmware that will still be running, file formats with a 32-bit field, and database columns typed INT rather than BIGINT. The last of those is the one most likely to be in your codebase right now.

Why is my ISO string an hour out?

Usually daylight saving. An offset is a property of a specific instant, not of a zone: London is +00:00 in January and +01:00 in July. This tool reads the offset from the platform's time zone database for your exact instant, so it changes across the boundary — which is correct, and which is why a hard-coded offset is wrong for half the year.

Does Unix time include leap seconds?

No, by definition — it counts non-leap seconds, which means it has no way to represent one. When a leap second is inserted, systems either repeat a timestamp value or smear the extra second across the day. The practical consequence is that subtracting two Unix timestamps gives you elapsed civil time, not elapsed physical time; they have differed by 27 seconds since 1972.

Is my timestamp uploaded?

No. Every conversion here is arithmetic plus the browser's own Intl time zone database, running in the tab you already have open. There is nothing about converting a date that needs a server, and the timestamps people convert usually come out of production logs.

ToolsByUs team · How we check our tools