🗓️ How to Convert a Unix Timestamp to a Date

You've probably seen a number like 1735689600 sitting where a date should be in a server log or an API response. This article covers what a Unix timestamp actually is and why it's used, why mixing up seconds and milliseconds is such a common source of bugs, and how to convert one to a real date.

What a Unix Timestamp Is

A Unix timestamp (also called Unix time or POSIX time) is a single integer representing the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — a reference point known as the Unix epoch. For example, 1735689600 means exactly 1,735,689,600 seconds have passed since the epoch. Because a date is represented as one number instead of a "year-month-day hour:minute:second" string, it's trivial to store, compare, and sort. Figuring out which of two events happened first is just comparing two integers, and finding records within a date range is a single inequality. Most importantly, a Unix timestamp is an absolute point in time anchored to UTC, so there's no need to store timezone information alongside it. Whether the server is in Seoul or New York, the same instant is represented by the same number — you only convert to the viewer's local timezone when displaying it. That's why timestamps are the de facto standard for handling time inside databases, log files, and API responses.

Why Seconds vs. Milliseconds Trips People Up

One of the most common mistakes in practice is confusing second-based and millisecond-based timestamps. The original definition of a Unix timestamp is in seconds — Linux's date +%s, PHP's time(), and most Unix-style APIs all return an integer number of seconds. JavaScript, on the other hand, is the odd one out: Date.now() and new Date().getTime() both return milliseconds. You can tell the two apart by digit count. As of the current era, a second-based timestamp has 10 digits (e.g. 1783929600), while a millisecond-based one has 13 (e.g. 1783929600000). Feed a second-based value straight into JavaScript's new Date() without converting, and you'll get a nonsensical date near January 1970; mistake a millisecond value for seconds and multiply it by 1000, and you'll land tens of thousands of years in the future. Whenever you're integrating an API or parsing logs, get in the habit of checking the digit count first.

A Worked Conversion Example

Take the second-based timestamp 1735689600. Converted, it's January 1, 2025, 00:00:00 UTC. To express the same instant in milliseconds, multiply by 1000 to get 1735689600000. Going the other direction — from a date back to a timestamp — you again need to be clear on whether you're working in UTC or a local timezone, or the resulting number will be off. Instead of doing this arithmetic by hand, it's much faster to use a tool that auto-detects seconds vs. milliseconds from the digit count and converts to a date, and converts a picked date straight back into a timestamp.

Working with Unix timestamps by language

Common idioms for getting the current Unix time (in seconds) and converting a timestamp back to a date across popular languages and environments.

Timestamps worth remembering

The UTC times above assume a seconds-based timestamp. In environments that use milliseconds (13 digits, e.g. JavaScript Date.now()), multiply or divide by 1000 to convert.

More Guides