Unix Timestamp Converter

What this tool does

It translates in both directions between a Unix timestamp and a readable date:

• Timestamp → date: gives you the instant in ISO 8601, in UTC, in your local time and in relative form (“3 days ago”), plus the day of the week.
• Date → timestamp: you pick a date and a time and get the number, in seconds and in milliseconds.

It works out on its own whether what you pasted is in seconds or milliseconds, and it keeps a live clock with the current timestamp for one-click copying.

What a Unix timestamp actually is

It is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970. That date is called the Unix epoch, it is defined by POSIX, and it carries no special meaning: it was chosen as a round, recent starting point when the system was designed.

Its virtue is that it is an integer. An integer has no ambiguous format (03/04/2026 is March in one country and April in another), no language, no time zone, and always takes the same space. That is why it is what databases store, what APIs send, and what logs write.

Its flaw is that a human cannot read it, and hence this page.

The three-zeros bug: seconds versus milliseconds

This is by far the most frequent failure when working with timestamps, and it has one concrete origin: JavaScript counts in milliseconds and almost everything else counts in seconds.

When a value crosses that boundary without being converted, the symptom is unmistakable:

• You get a date in January 1970. You had milliseconds and they were read as seconds: the number is so small on that scale that it lands at the very start of the epoch.
• You get an absurd year, something like 58000. You multiplied by a thousand by accident, or you passed seconds to a function that expected milliseconds and then multiplied them again.

The quick rule for telling what you are looking at: count the digits. Today a timestamp in seconds has 10; in milliseconds, 13. That will hold for decades.

In JavaScript the conversion is:

// seconds → Date object
new Date(1771200000 * 1000)

// Date → timestamp in seconds
Math.floor(Date.now() / 1000)

The Math.floor matters: without it you carry decimals that other layers reject.

Why the time “doesn’t match”

A timestamp has no time zone. It represents an absolute instant, the same one for the whole planet. The time zone only appears when you display it.

That means two people looking at the same number will see different times and both will be right. If a log shows 2026-02-16 10:00 and your screen says 04:00, nothing is wrong: the log is in UTC and you are in UTC−6.

That is why this tool shows UTC and your local time at once, and tells you what offset your machine has. When you are debugging a value that “arrives wrong”, always compare against the UTC figure.

The practical corollary, which saves many hours: always store in UTC and convert only on display. A database with dates in local time is a database that breaks twice a year, when daylight saving changes.

The year 2038 problem

2147483647 is the largest number that fits in a signed 32-bit integer, and it corresponds to 19 January 2038 at 03:14:07 UTC.

One second later, a system storing the timestamp in 32 bits overflows: the number goes negative and is read as 13 December 1901. It is the same class of failure as Y2K, but with an exact, known date.

Who it still affects:

• Old C software using a 32-bit time_t.
• Databases with 32-bit TIMESTAMP columns — in MySQL that is TIMESTAMP, which stops at 2038, while DATETIME reaches 9999.
• Embedded systems and devices that never get updated.

The fix is to use 64 bits, which modern operating systems already do, and which buys roughly 292 billion years of headroom. If your MySQL column is TIMESTAMP and you store future dates (expiry dates, contracts, long-term subscriptions), the problem is not a 2038 problem: it is a today problem, because a date in 2040 already does not fit.

Where this gets used day to day

• Reading a log or a trace where the error is stamped with a number.
• Checking a JWT’s expiry: the exp claim is a Unix timestamp, and the date comes out here. The JWT decoder reads the whole token.
• Debugging an API response that returns created_at as an integer.
• Writing a SQL query with a date range converted to timestamps.
• Scheduling a job and checking which instant it corresponds to.