Unix Timestamp Converter

Unix Timestamps Without the Headache

Ask three developers what time it is and you might get three answers, depending on where they sit. Ask a Unix timestamp and you get exactly one number, the same for everyone on the planet. That single integer is why epoch time quietly underpins almost every log file, database row, and API response you will ever touch. This page explains what that number means, how to read it in both directions, and where it tends to bite people.

What Unix time actually is

A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. That moment is called the epoch, and it was chosen by early Unix engineers simply because it was a convenient round date to count from. At the epoch the value is exactly 0. Every second since then adds one, so the number only grows. Dates before 1970 are perfectly valid too, expressed as negative integers.

You will also see this concept called POSIX time or, loosely, epoch time. Whatever the label, the mechanics are the same: one ever-increasing counter of seconds. Because it is a plain integer rather than a formatted string, a computer can store it in a few bytes and compare two of them with a single subtraction.

Seconds, milliseconds, and friends

Classic Unix time counts whole seconds, which gives the familiar ten-digit number you see today. But many environments need finer resolution. JavaScript, for instance, works in milliseconds, producing a thirteen-digit value, and some systems go further into microseconds or nanoseconds. A reliable rule of thumb: a ten-digit number is seconds, thirteen digits is milliseconds. If your converted date lands somewhere around 1970 when you expected the present day, you almost certainly fed milliseconds into a seconds field, or the reverse. Our converter auto-detects the magnitude so you rarely have to guess.

Why developers lean on it

The big win is that a timestamp is timezone-neutral. The integer 1735689600 refers to the same instant in Tokyo, Berlin, and São Paulo. Storing that number instead of a formatted local string means you never have to wonder which clock a value belonged to. Sorting is trivial as well, because chronological order is just numerical order, so a database index over a timestamp column sorts events correctly with no parsing. Arithmetic is equally clean: the gap between two events is one subtraction, and adding a day is adding 86400. These properties are exactly why logs, tokens, caches, and message queues all reach for epoch time.

Converting both ways

Going from a timestamp to a human date means taking the count of seconds and projecting it onto a calendar, then formatting that in whatever timezone you care about. Going the other way, you take a year, month, day, and time, decide which timezone it is expressed in, and collapse it back to seconds since the epoch. Our tool does both directions instantly and entirely in your browser, so nothing you paste leaves your machine. Paste a number to decode it, or pick a date to encode it, and read the result in both UTC and your local time at the same moment.

UTC versus local time, the classic trap

The timestamp itself has no timezone; it is always anchored to UTC. The confusion appears only when you display it. If you convert 1700000000 and your screen shows an evening hour while a colleague in another country sees an afternoon, nothing is broken, you are both looking at the same instant rendered in different local clocks. Bugs creep in when code reads a local date as if it were UTC, or stamps a wall-clock time without recording the offset. The safe habit is to store and transmit UTC, and only apply a local offset at the very last moment, when you show the value to a person. When in doubt, compare against the UTC line in the converter rather than your local one.

The year 2038 problem

Many older systems stored Unix time in a signed 32-bit integer. That field runs out of room one second after 03:14:07 UTC on 19 January 2038, when the counter overflows and wraps around to a negative number, potentially throwing dates back to 1901. It is the same family of issue as Y2K. The good news is that modern operating systems and languages have largely moved to 64-bit timestamps, which will not overflow for roughly 292 billion years, so for new code it is mostly a historical curiosity worth knowing about rather than an emergency.

For more browser-based helpers see our developer tools, and if you need to work the numbers themselves, the calculators are a click away.

Frequently asked questions