Unix Timestamp Converter Guide: Epoch Time, Seconds vs Milliseconds

A Unix timestamp counts the seconds elapsed since 00:00:00 UTC on 1 January 1970, an instant known as the Unix epoch. No calendar fields, no month names, no daylight saving adjustments and no offset suffix. Just one integer that ticks upward, forever, at a rate of one per second.

The simplicity is the point. Because time is reduced to a single number, computers can store it compactly, compare two moments with a single subtraction, and sort events with an ordinary numeric sort, without worrying about calendars or time zones at any step. The messy business of leap years and local offsets gets pushed to the moment of display, where a human is looking anyway. Dates are for people; timestamps are what machines actually pass around.

Most languages and platforms count seconds. C, Python, PHP and the date command in a Unix shell all produce a 10-digit number that sits around 1.7 billion right now. JavaScript is the famous outlier: Date.now() returns milliseconds since the same epoch, which is a 13-digit number. The two conventions meet constantly, because the front end of an application so often talks to a back end written in something else.

Neither value announces its unit, and the numbers look similar enough at a glance to pass inspection. Feed a 13-digit millisecond value into a seconds-based converter and you land tens of thousands of years in the future. Send a 10-digit value the other way and you arrive somewhere in January 1970, weeks after the epoch. When a converted date looks absurd, count the digits before you suspect anything else.

A common worry is that a timestamp recorded in Tokyo will mean something different when a server in Frankfurt reads it. It will not. The number is always UTC-based and identical everywhere on Earth, because it counts seconds from one fixed instant rather than describing a position on any local calendar.

Only the human-readable display changes with your time zone. The same timestamp shows different wall-clock times in different zones, an evening in Berlin while it is still morning in New York, yet the underlying number never moves. So when a timestamp seems to be wrong by a few hours, the number is usually fine. The display side converted it into a time zone nobody expected, which is a rendering decision, not a data problem.

The epoch is zero, and time runs in both directions from it. A negative timestamp is simply a moment before 1 January 1970, which is exactly what you get for birth dates, historical archives and old mission logs. There is nothing special or malformed about the minus sign; a converter that handles it is doing the format justice, not a favour.

The other edge sits in the future. Systems that store time as a 32-bit signed integer run out of room at 2,147,483,647, which corresponds to 03:14:07 UTC on 19 January 2038. One second later the value overflows and wraps negative, and the clock appears to jump back before 1970. That is the Y2038 bug, structurally the same species of problem as Y2K: a storage assumption that outlived its designers. Storing time in 64-bit integers avoids it entirely, which is why most modern systems have quietly made the switch.

A Unix timestamp converter needs to work both ways, and ours does. Paste a timestamp to get a readable date, or pick a date and time to get its timestamp back. Seconds and milliseconds both appear in the results, so the digit-counting trap from earlier becomes something you can see rather than guess at.

That covers the everyday cases: reading log files, decoding rows in a database dump, checking file modification times, and interpreting date fields in an API response. Conversion runs locally in your browser, so nothing is uploaded. A bare timestamp is rarely sensitive on its own, but the log lines and database rows that contain them often are, and local conversion lets you decode those without pasting internal data into a server you have never heard of.