Unix timestamp converter

What Unix time is

Unix time — also called epoch time or POSIX time — is how most computers keep track of the clock: a single integer counting the seconds elapsed since January 1, 1970 at 00:00:00 UTC, an instant known as the Unix epoch. There are no time zones baked in, no months, no daylight saving rules: just a counter ticking up once per second. Leap seconds are deliberately ignored, so every day is exactly 86,400 seconds long.

That bare-bones design is the whole point. Comparing two dates becomes comparing two integers, a duration is a subtraction, and the same number means the same instant whether the machine sits in London, São Paulo or Tokyo.

How to use this converter

1. The live clock at the top shows the current timestamp in both seconds and milliseconds, refreshing every second — copy either value with one click.
2. Paste any timestamp into Timestamp to date. The tool detects whether it is in seconds (10 digits) or milliseconds (13 digits) and labels it for you.
3. Read the result twice: once in your browser’s local time zone and once in UTC, so you can spot offset mistakes immediately.
4. Going the other way, pick a date and time under Date to timestamp to get the value in seconds and milliseconds, each with its own copy button.

Seconds vs milliseconds

Unix-like systems and languages such as Python and PHP count in seconds by default. JavaScript counts in milliseconds: Date.now() returns a 13-digit number. The fastest tell is the length — a present-day timestamp has 10 digits in seconds and 13 in milliseconds. Mix them up and the symptoms are unmistakable: milliseconds read as seconds throw the date tens of thousands of years into the future, while seconds read as milliseconds collapse everything into January 1970.

Worked example

Take 1700000000 — ten digits, so seconds. That is Tuesday, November 14, 2023 at 22:13:20 UTC. In New York the clocks were on EST (UTC−5) by mid-November, so it reads 5:13:20 PM the same day; in Tokyo (UTC+9) it is already 7:13:20 AM on November 15. Three clocks, one instant. Written in milliseconds, the identical moment is 1700000000000.

The Year 2038 problem

Older systems store Unix time in a signed 32-bit integer, which tops out at 2,147,483,647. That counter overflows on January 19, 2038 at 03:14:07 UTC — one tick later the value wraps around and decodes as a date in December 1901. Think of it as Y2K’s binary cousin. The fix is already rolling out: modern kernels, databases and languages store the value in 64 bits, enough headroom for roughly 292 billion years. What remains at risk is embedded hardware and unmaintained legacy code.

Notable timestamps

A timestamp has no time zone

A Unix timestamp does not “live” in any time zone. 1700000000 names one instant for the entire planet; only the human-readable rendering changes — 22:13 in London, 17:13 in New York, 07:13 the next morning in Tokyo. That is why this tool prints the local and UTC renderings side by side.

Frequently asked questions

Why is my date off by one day?

Almost always a time zone issue. A timestamp near midnight UTC can land on “yesterday” in the Americas: 1700006400 is November 15, 2023 at 00:00 UTC, but in New York it is still 7:00 PM on the 14th. Check the UTC card against the local card before blaming your data.

How do I get the current timestamp in JavaScript, Python or SQL?

• JavaScript (milliseconds): Date.now() — in seconds: Math.floor(Date.now() / 1000)
• Python: int(time.time()) (after import time)
• MySQL: SELECT UNIX_TIMESTAMP(); — PostgreSQL: SELECT extract(epoch from now());

What will actually happen in 2038?

On systems already migrated to 64-bit time, nothing. On unpatched 32-bit software, the counter overflows on January 19, 2038 at 03:14:07 UTC and dates jump back to 1901, corrupting any calculation built on them. Recent Linux kernels, mainstream databases and modern languages are safe; the exposure is concentrated in old embedded devices.