Unix Timestamp Converter

What the number actually is

A Unix timestamp is a count of seconds from a single fixed instant: midnight UTC on 1 January 1970. That instant is the Unix epoch, and the count is why the format exists. It is one integer, it has no time zone, no daylight saving, no calendar and no locale. Two servers on opposite sides of the planet agree on what 1757308800 means without agreeing on anything else.

That makes it the right thing to store and the wrong thing to show a person. Somewhere between the database and the screen it has to become a date, and that conversion is where time zones, formats and off by one hours enter. This page does that conversion in both directions and shows the same instant three ways, because the difference between them is usually the thing you are trying to see.

Seconds, milliseconds, and the bug everyone hits

The single most common problem with epoch values is not the maths, it is the unit. Most systems, most databases and most languages count seconds. JavaScript counts milliseconds, as do Java and many APIs built on them. Go and Python logs often carry nanoseconds or microseconds. The number looks the same until it is a thousand times wrong.

The failure is quiet, which is what makes it expensive. Give a seconds value to something expecting milliseconds and you get a date a few weeks after 1970. Give a milliseconds value to something expecting seconds and you get a date tens of thousands of years in the future. Neither throws an error. Both look like a bug somewhere else.

The digit count settles it in practice. Ten digits is seconds and has been since September 2001. Thirteen is milliseconds. Sixteen is microseconds. Nineteen is nanoseconds. This tool applies that rule and then says which unit it used, because a converter that guesses silently is a converter that can be wrong without telling you. Override it with the unit selector when you already know.

Why there is no time zone in it

A timestamp is an instant, not a wall clock reading. The same value is 14:00 in London and 09:00 in New York at the same moment, and the number does not change. This is the opposite of how people talk about time, which is always local, and the mismatch is the root of most timestamp bugs.

So the panel above shows three renderings of one instant. ISO 8601 in UTC is the form to put in a log or an API, and is unambiguous everywhere. The UTC string is the form HTTP headers and older tooling use. Your local time is the one to check against your own clock when you are trying to work out whether a record was written when you think it was. If those three disagree with your expectation by exactly one hour, daylight saving is the first thing to suspect.

The reverse panel makes the same distinction explicit. When you type a date and time, it has to be read as something, so you choose: your own zone or UTC. Most tools guess, and the guess is the reason a converted timestamp is sometimes a few hours out.

The year 2038

A signed 32 bit integer stops at 2147483647. As a Unix timestamp that is 03:14:07 UTC on 19 January 2038. One second later it overflows to a negative number, which reads as 13 December 1901. This is the same shape of problem as the year 2000, with a fixed and known date.

Most modern systems moved to 64 bit values long ago and are fine for roughly 292 billion years. What has not moved is the long tail: embedded controllers, industrial equipment, file formats with a fixed layout, database columns declared as a 32 bit integer years ago and never revisited, and anything compiled once and never touched since. Enter a timestamp past that boundary above and this page says so, because a value that is fine in your code today may not survive whatever it is written into.

Before 1970, and the leap second question

Negative timestamps are instants before the epoch. Minus 86400 is 31 December 1969. They are valid, and a surprising amount of software rejects them, truncates them or renders them as 1970. If you work with historical data, test that path rather than assuming it.

Unix time also does not count leap seconds. Every day is exactly 86400 seconds by definition, so the value is not truly the number of seconds that have elapsed since 1970: it is about thirty short. When a leap second is inserted, the count repeats or stretches a value rather than passing through an extra one. That was a deliberate trade. It means date arithmetic is plain division, that no system needs a table of past leap seconds to convert a timestamp, and that the format stays simple at the cost of being very slightly untrue.

Related tools

To see one instant in several cities at once, use the time zone converter. To find a time that suits people in different places, the meeting planner searches a whole day rather than converting a single moment. For the current time around the world, there is the world clock, and for the gap between two clock times, the hours calculator.