Unix Timestamp Converter

What a Unix timestamp is

A Unix timestamp counts whole seconds elapsed since 1970-01-01T00:00:00Z, known as the Unix epoch. The date was chosen as a convenient recent round number when Unix was developed in the early 1970s, nothing more.

The appeal is simplicity. A timestamp is a single integer, so comparing two moments is an integer comparison, sorting is trivial, and storage is compact. There is no parsing, no ambiguity about date formats, and no regional convention to get wrong.

Negative values are valid and represent dates before 1970. For example -86400 is 1969-12-31.

A timestamp has no time zone

This point causes persistent confusion. A Unix timestamp is always UTC. It identifies an absolute moment, not a local wall-clock reading.

The timestamp 1700000000 refers to the same instant everywhere on Earth. What differs is how that instant is displayed: 22:13 in London, 23:13 in Berlin, 17:13 in New York. The timestamp itself does not change.

This is exactly why timestamps are the right thing to store. Recording local times invites daylight saving bugs, since some local times occur twice a year and others never occur at all. Store the timestamp, convert to local time only for display.

Seconds versus milliseconds

The most common practical error. Unix timestamps are conventionally in seconds, but several environments use milliseconds:

Quick sanity check: a current timestamp in seconds has 10 digits, in milliseconds 13. If a date comes out in 1970, you passed milliseconds to something expecting seconds. If it lands around the year 55000, the reverse. This tool uses seconds.

Examples

Useful intervals: an hour is 3600 seconds, a day 86,400, a week 604,800, a non-leap year 31,536,000.

The year 2038 problem

Systems storing timestamps in a signed 32-bit integer can represent at most 2,147,483,647 seconds, which runs out on 19 January 2038 at 03:14:07 UTC. One second later the value overflows to negative, and naive code interprets it as December 1901.

This is the same class of problem as Y2K. Modern systems use 64-bit timestamps, which last for roughly 292 billion years, so the issue is largely solved on current platforms. It persists in embedded devices, legacy databases, and file formats with fixed 32-bit fields, which is why it is still worth knowing about when working with older systems.

Practical notes

Leap seconds are ignored

Unix time pretends every day has exactly 86,400 seconds, which is not quite true: leap seconds are occasionally inserted to keep clocks aligned with the Earth's rotation. Unix time handles these by repeating or skipping a second rather than counting it. Consequently Unix time is not a true count of elapsed SI seconds since 1970, though the difference is under a minute and irrelevant for nearly all applications.

Storing timestamps in databases

Either store an integer timestamp or use a timezone-aware type such as PostgreSQL's timestamptz. What causes trouble is a naive datetime column with no zone information, where the intended interpretation depends on unwritten convention and breaks when a server moves or a second application connects.

Timestamps in JWTs

The exp, iat, and nbf claims in a JSON Web Token are Unix timestamps in seconds. Pasting one here converts it to a readable date, though the JWT decoder does this automatically.

Frequently asked questions

Milliseconds or seconds?

This tool uses seconds, the standard Unix convention. JavaScript's Date.now() returns milliseconds, so divide by 1000 first.

Why is my date showing as 1970?

Almost always because milliseconds were passed to something expecting seconds, or the value is zero or empty. A current timestamp in seconds has 10 digits.

Do Unix timestamps have a time zone?

No. They are always UTC and identify an absolute instant. Time zones only affect how that instant is displayed.

Can timestamps be negative?

Yes, negative values represent dates before 1 January 1970. Some older systems and libraries handle them poorly, so test if you rely on them.

What happens in 2038?

Signed 32-bit timestamps overflow on 19 January 2038. Modern 64-bit systems are unaffected, but legacy embedded devices and old file formats may still be at risk.

What if I enter an absurdly large or negative timestamp?

You get a clear error rather than a technically valid but meaningless date thousands of years away.

Related tools

• .NET ticks converter, for the .NET DateTime representation
• JWT decoder, which reads timestamp claims automatically
• Cron expression explainer, for scheduled times
• All developer tools