Unix Timestamp Converter

What an Epoch Timestamp Is

A Unix timestamp counts how many seconds have passed since midnight on 1 January 1970 in universal time. That instant is called the epoch, and it was chosen simply because it was a convenient round date shortly before Unix was written.

The appeal is that it is one number. Comparing two moments is comparing two integers, sorting is trivial, and there is no ambiguity about format, calendar or region. Almost every system stores time this way internally and formats it only for display.

Negative values are valid and represent moments before 1970, which is how systems store historical dates. Not every library handles them correctly, so they are worth testing if you deal with birth dates or archives.

Leap seconds are not counted. Unix time pretends every day has exactly 86,400 seconds, which keeps arithmetic simple at the cost of drifting slightly from atomic time.

Seconds, Milliseconds and Microseconds

The original definition is seconds, and that is what Unix tools, most databases and most APIs return. A current value has ten digits.

JavaScript works in milliseconds, so Date.now() returns thirteen digits. Java does the same. Mixing the two is the single most common epoch bug, and it fails loudly by a factor of a thousand: a millisecond value read as seconds lands in the year 58,000.

Microseconds, sixteen digits, appear in high resolution logging, in PostgreSQL timestamps and in some tracing systems. Nanoseconds, nineteen digits, show up in Go and in metrics pipelines.

This tool infers the unit from the digit count, which is reliable for any date in the current era, and tells you which unit it assumed rather than deciding silently.

Why an Epoch Value Has No Time Zone

The number counts from a fixed instant in UTC, so it identifies a moment rather than a reading. Everyone on Earth shares the same timestamp at the same moment.

Zones enter only at the edges: when a human types a date that must become a timestamp, and when a timestamp is displayed to a human. Everything in between should stay numeric.

This is why storing epoch values is good practice and storing formatted local strings is not. A timestamp survives a server move, a daylight saving change and a locale switch; a string saying 03/04/2026 09:00 survives none of them.

The exception is a future event tied to a place. A meeting at nine in Warsaw next December should store the local time and the zone name, because if the government changes the rules the intention is nine in Warsaw, not a fixed instant.

ISO 8601 and the Other Formats

ISO 8601 is the format to use when a timestamp must be human readable and machine parseable at once. The trailing Z means UTC, and the ordering means the strings sort chronologically as text, which is quietly very useful.

RFC 2822 is the older form still used in email headers and in some HTTP contexts. It is readable but wordy and awkward to parse.

Locale formats are for display only. Third of April is 04/03 in the United States and 03/04 nearly everywhere else, which makes them unusable for storage or exchange.

The Year 2038 Problem

A signed 32 bit integer runs out on 19 January 2038, at 03:14:07 UTC. One second later it overflows to a negative number, which reads as December 1901.

Most modern systems moved to 64 bit time long ago, which pushes the limit past the lifetime of the sun. The risk sits in embedded devices, old file formats and legacy databases where the width was fixed decades ago.

It bites earlier than 2038 in practice. Anything calculating a date thirty years ahead, such as a mortgage or a certificate expiry, already crosses the boundary today.

Where Epoch Handling Goes Wrong

Mixing units. Passing milliseconds where seconds are expected produces dates tens of thousands of years out. It is obvious once seen and easy to miss in a log.

Assuming local time on parse. Some parsers treat a bare date string as local and others as UTC, which shifts the result by your offset and produces off by one day errors near midnight.

Storing formatted strings. They lose the zone, sort wrongly and break when the locale changes. Store the number.

Using timestamps for durations across a clock change. The arithmetic is correct in elapsed seconds but may not match what a calendar says, because one day that year was not twenty four hours long.

Getting the Current Timestamp in Code

JavaScript gives milliseconds from Date.now(), so divide by a thousand and floor it for seconds.

Python returns a float in seconds from time.time(), which keeps sub second precision. Use int() when a whole number is expected.

PHP has time() in seconds, and Go offers both Unix() and UnixNano(), which is where nineteen digit values come from.

On the command line, date +%s prints seconds on Linux and macOS, and the reverse conversion differs between GNU and BSD date, which catches people moving between them.

Frequently Asked Questions