Unix Timestamp Converter

The number of seconds between 1 January 1970 at 00:00:00 UTC and the moment in question, with no time zone attached. It can be negative for earlier moments, and it deliberately ignores leap seconds, so Unix time treats every day as 86,400 seconds. That is why a timestamp can be converted in one step and why a wall clock derived from one can differ from an official broadcast time by a second.

Almost always because the unit is different from what this page assumed. Ten digits is seconds, thirteen is milliseconds (JavaScript), sixteen is microseconds and nineteen is nanoseconds. A millisecond value read as seconds lands in January 1970; a seconds value read as milliseconds lands in the year 56,000 and is usually outside the range of dates a record can hold at all. The unit setting overrides the reading, and the results always state which reading was used and what the other one would have been.

Because of the zone, and this is usually daylight saving. New York is -05:00 in January and -04:00 in July; Berlin is +01:00 and +02:00; India is +05:30 all year. The offset printed here is the one that applied at that instant rather than today’s, so a July timestamp converted in the Europe/Berlin zone shows the summer offset. If a time looks an hour out, check the zone field and the offset on the row rather than the arithmetic.

Plenty of software stores a timestamp as a signed 32-bit integer, which runs out at 2,147,483,647 seconds: 19 January 2038 at 03:14:07 UTC. The value is inside the range of a JavaScript date, so it converts here perfectly well - the problem is in the old software that can no longer hold it. Modern systems use 64 bits, which reaches the year 292 billion, and JavaScript uses milliseconds, which are safe until the year 275,760.

Both have a job. A number is compact, sorts correctly, carries no zone ambiguity and arithmetic on it is trivial - which is why databases and APIs use it. A date string is readable by a person and self-describing, which is why they are used for interchange and logs. The mistake worth avoiding is a bare number whose unit is not written down anywhere: name the column for its unit (`created_at_ms` rather than `created`), because ten digits and thirteen digits look alike and mean wildly different things.

Because it cannot be read unambiguously. `12/25/2026` is Christmas in the United States and the 12th of the 25th month everywhere that writes the day first, and the browser would have to guess - which is exactly what `Date.parse` does, differently in different browsers. Dates here are ISO 8601: 2026-12-25, optionally with a time and a zone. It takes a moment longer to type and removes a whole class of bug.

Not safely on its own. A timestamp comes from a wall clock, and wall clocks are corrected: NTP can move a clock backwards by a fraction of a second, and a virtual machine coming back from a snapshot can move it back much further. For ordering within one machine, use a monotonic clock or a sequence number; for ordering across machines, use a timestamp plus a tiebreaker such as a logical clock or an identifier that embeds the time and a counter. Timestamps are for "when did this happen", not for "which came first".

Because Unix time has no second number 60: a day is defined as 86,400 seconds, and the leap second is absorbed rather than counted. Stored data almost always writes 2016-12-31T23:59:60 as the first second of the next minute, which is what this page will accept and convert. If you have a value that genuinely says :60, it came from a broadcast time scale rather than from a Unix timestamp.