Unix Timestamp Converter

What a Unix timestamp is

A Unix timestamp is a single number: how many seconds have passed since the start of 1970 in UTC. That is all. It carries no time zone, no daylight saving, no calendar and no formatting, which is precisely why it is what systems store and exchange. Two servers on opposite sides of the world agree on the number even when they disagree about what to call it.

The flip side is that a timestamp alone cannot answer "what time was it". It can tell you the instant, but turning an instant into a wall-clock reading needs a time zone, and that is information the number does not contain. This is why a converter has to show you the UTC reading and your local reading as two separate answers rather than one.

How to use it

• Timestamp to date paste the number. The unit is detected by its size, and the result shows the ISO 8601 form, your local time, the weekday and how long ago it was.
• Date to timestamp type a date. 2026-03-02, 2026-03-02T14:30:00Z and 2026-03-02T14:30:00+01:00 all work, and give different answers, correctly.
• Read as force seconds or milliseconds when the automatic guess is not what you want, which happens with timestamps from before 1973 or very far in the future.
• Use the current time fills in now, which is the fastest way to see what a timestamp near today should look like.
• Watch for the zone warning if the date you typed carries no zone, the page says so. That is the difference between a correct answer and an answer that is right only on your laptop.

The time zone trap, in detail

Three strings that look almost identical mean three different instants. 2026-03-02 is UTC midnight, because the ISO 8601 date-only form is defined that way and JavaScript follows it. 2026-03-02T00:00:00 has a time but no zone, so it is local midnight, which in Rome is 23:00 the previous day in UTC. And 2026-03-02T00:00:00Z is explicitly UTC again. One of those three will be what you meant; the other two are bugs waiting for someone in a different country to run your code.

Daylight saving makes it worse in a way no number can fix. In most of Europe the last Sunday in March has no 02:30 at all, the clocks jump from 02:00 to 03:00, and the last Sunday in October has two of them. A timestamp handles this fine, because it never left UTC. A local time written as text does not: 02:30 on that Sunday either does not exist or is ambiguous, and whatever your library does with it is a guess.

The practical rule that follows: store the instant, format at the edge. Keep timestamps or UTC in your database, convert to the reader’s zone when you display, and never do arithmetic on a local time string. The hour you add to 01:30 on the wrong Sunday is not the hour you think.

When a Unix timestamp converts to the wrong date

• The date comes out in 1970 a millisecond value was read as seconds, dividing the age of your timestamp by a thousand. Force milliseconds.
• The date is tens of thousands of years away the opposite: seconds read as milliseconds. Force seconds.
• Off by exactly one or two hours a zone, almost always. One hour is standard offset, two is offset plus daylight saving; neither is a rounding error.
• Off by exactly one day a date-only string being read as UTC midnight on one side and local midnight on the other. Add an explicit zone and it goes away.
• Negative timestamps perfectly valid: they are dates before 1970. Some systems reject them anyway, which is a bug in those systems and a thing to test for.
• A JWT that seems expired when it is not the exp claim is in seconds, and code that compares it to Date.now(), which is milliseconds, will think every token expired in 1970.

The words around it

• Epoch the zero point a time system counts from. The Unix epoch is 1970-01-01T00:00:00Z; other systems picked other dates, which is why a timestamp from one platform can be decades off in another.
• UTC the reference time everything converts against. Not a time zone anyone lives in, and not the same thing as GMT in a strict sense, though the two agree to within a second.
• ISO 8601 the text format: 2026-03-02T14:30:00Z. Sorts correctly as a string, which is why it is the right choice for a log or a filename.
• Leap seconds extra seconds added to keep clocks in step with the Earth. Unix time ignores them by definition, which is why it is a clean counter and not a true count of elapsed seconds.
• The year 2038 problem a signed 32-bit timestamp overflows on 19 January 2038. Anything storing Unix time in an int32, old embedded systems, some database columns, stops working or jumps to 1901.