How to Convert a Unix Timestamp to a Readable Date

Paste a Unix timestamp like 1735689600 into a chat message and nobody will know what date you mean. That's by design — the format exists for machines, not people — but turning it back into something readable is a five-second job once you know the method, whether you're doing it by hand or with a single line of code.

This guide walks through both: the manual arithmetic that shows exactly what's happening underneath, and working code for JavaScript, Python, SQL, and spreadsheets. If you'd rather skip straight to an answer, the Unix timestamp converter does it instantly; if you want to understand the method, keep reading.

Two things are worth confirming first. The first is the unit: most Unix timestamps count seconds (a 10-digit number today), but plenty of systems — including JavaScript's own Date.now() — use milliseconds instead. Everything below assumes seconds unless stated otherwise; if you're not sure which you have, see the full digit-count breakdown in What Is a Unix Timestamp?

The second is the starting point: every Unix timestamp counts forward from 00:00:00 UTC on 1 January 1970, the Unix epoch. You don't need its backstory to convert a timestamp, but if you're curious why that date was chosen, it's covered in Unix Epoch Time Explained.

A Unix timestamp in seconds converts to a date in two stages: split it into whole days and leftover seconds, then turn the leftover seconds into a clock time and the day count into a calendar date.

• Divide by 86,400 (the seconds in a day) and take the whole number — that's how many days have passed since 1 January 1970.
• Whatever's left over after that division is how many seconds into that day you are.
• Divide the remainder by 3,600 for hours, then divide what's left of that by 60 for minutes; whatever remains after both is seconds.
• Count the day total forward from 1 January 1970, one calendar year at a time (adding an extra day for each leap year you pass), to land on the actual date.

Enter a Unix timestamp in seconds and see both the final date and the days/remainder breakdown from the method above.

Every mainstream language and tool has a built-in for this, so in practice you'll rarely do the arithmetic above by hand. Here's the equivalent one-liner in each, converting the same example timestamp, 1735689600:

Once you have the UTC date and time, showing it in a particular place's local time is a matter of applying that place's offset — and almost every language will do this for you if you ask, rather than requiring you to add the offset by hand. JavaScript's Intl.DateTimeFormat and Python's zoneinfo module both accept a named time zone (such as "Asia/Karachi" or "America/New_York") and return the correctly adjusted local date and time, including daylight saving where it applies. For the concept behind why this offset step exists at all, see What Is UTC?

A 13-digit timestamp is almost always milliseconds, not seconds. Divide it by 1,000 before running it through the manual method above, or, in JavaScript specifically, skip that step entirely — its Date constructor already expects milliseconds, so new Date(ts) is correct as-is for a millisecond value. For the full digit-count reference across seconds, milliseconds, microseconds, and nanoseconds, see What Is a Unix Timestamp?

• Multiplying or dividing by 1,000 incorrectly. Forgetting to convert seconds to milliseconds for JavaScript's Date, or doing it twice on a value that was already in milliseconds, is the single most common error here.
• Calling a "local" function when you meant UTC. Python's datetime.fromtimestamp(ts) without a tz argument silently uses the system's local time zone instead of UTC.
• Assuming a database function returns UTC. As shown above, several SQL date functions actually return the session's configured time zone.
• Passing the wrong precision into an older function. Some legacy or embedded date functions expect a 32-bit seconds value and can overflow or error out if handed milliseconds or a timestamp far in the future.