How to Convert a Unix Timestamp to a Readable Date Manually

To convert a Unix timestamp to a readable date, divide the seconds by 86,400 to get days since January 1, 1970, then add those days: 1,700,000,000 seconds is 19,675 days later, which is November 14, 2023. Skip the arithmetic with our free Unix Timestamp Converter, and read on for the epoch math, the code versions, and the timezone trap.

Try it now: Unix Timestamp Converter →

What a Unix Timestamp Actually Counts

A Unix timestamp counts seconds since midnight UTC on January 1, 1970, a moment called the epoch, and every timestamp is just that count. A timestamp of 0 is January 1, 1970 itself, a timestamp of 86,400 is January 2, 1970, because 86,400 is the number of seconds in one day, and a timestamp of 1,000,000,000 is September 9, 2001, the day the count passed one billion. The first thing to check about any timestamp is its length: a 10-digit timestamp counts seconds, while a 13-digit timestamp counts milliseconds, and confusing the two is the most common conversion error. A 13-digit value like 1,700,000,000,000 is not the year 55,000; it is 1,700,000,000 seconds with three extra millisecond digits, so divide by 1,000 first and then convert. A 16-digit timestamp counts microseconds, and a 19-digit one counts nanoseconds, both used by databases and high-resolution timers. Negative timestamps exist too: they count seconds before the epoch, so minus 86,400 is December 31, 1969. The timestamp itself carries no timezone, no daylight saving, and no calendar information; it is a single number, and every readable date derived from it depends on the timezone you choose to display it in, which is the subject of a later section. Developers meet timestamps in APIs, logs, databases, and JWT tokens, and being able to read one by hand, even roughly, turns an opaque number into a debuggable fact.

Epoch Math Step by Step: The Worked Example

The manual method for converting a Unix timestamp to a readable date has four steps, and the worked example uses 1,700,000,000. Step one: divide by 86,400, the seconds in a day, so 1,700,000,000 divided by 86,400 is 19,675.93 days. Step two: take the whole days, 19,675, and the leftover fraction, 0.93 of a day, which is about 22.3 hours, so the time of day is roughly 22:20 UTC. Step three: add 19,675 days to January 1, 1970, and the calendar arithmetic lands on November 14, 2023, which you can verify by counting years: 53 full years from 1970 takes you to 2023, accounting for 13 leap days in that span, and the remaining days fall in November. Step four: apply the time of day, giving November 14, 2023 at about 22:13 UTC, and the exact value is 22:13:20 UTC. In practice nobody does the year-counting by hand for a production value; the manual method exists so you can estimate and verify, not replace a converter. Two estimation anchors make rough reading fast: 1,000,000,000 is September 2001, 1,500,000,000 is July 2017, and each additional 31,536,000 seconds is about one year, so a timestamp near 1,730,000,000 must be late 2024, and one near 1,600,000,000 must be late 2020. For the exact answer in one click, our Unix timestamp converter does the same arithmetic without the leap-year counting, and our guide to converting a Unix timestamp to a date in Excel covers the spreadsheet version of this method.

How to Read a Unix Timestamp in JavaScript, Python, and Excel

How to read a Unix timestamp in code depends on the language, but every version does the same thing: multiply or divide to seconds, then format. In JavaScript, new Date(1700000000 * 1000) creates the date, because JavaScript dates count milliseconds, so seconds must be multiplied by 1,000, and the result formats with toISOString for UTC or toLocaleString for local time. Forgetting the times-1,000 step is the classic JavaScript bug: new Date(1700000000) without it gives January 20, 1970, not November 2023, because the value is read as milliseconds. In Python, datetime.fromtimestamp(1700000000, timezone.utc) gives the UTC date directly, and datetime.fromtimestamp without a timezone gives local time, which is the difference that causes most off-by-hours bugs. In Excel, the formula is =(A1/86400)+DATE(1970,1,1), formatted as a date, because Excel counts days since January 1, 1900, and the 1970 epoch must be added as a base date; for a 13-digit millisecond timestamp, divide by 86,400,000 instead. In SQL, FROM_UNIXTIME does the same job in MySQL, and to_timestamp does it in PostgreSQL. The pattern is identical everywhere: normalize to seconds, add the epoch, then choose a timezone for display. When a value looks wrong, check three things in order: is it seconds or milliseconds, is the display timezone UTC or local, and is the epoch base 1970 or 1900, because those three choices explain nearly every wrong date a developer sees.

The Timezone Trap and the Year 2038 Problem

The timezone trap is that the same Unix timestamp is a different readable date in different places, and neither is wrong. Timestamp 1,700,000,000 is November 14, 2023 at 22:13 UTC, but it is November 14 at 17:13 in New York, November 14 at 14:13 in Los Angeles, and November 15 at 09:13 in Tokyo, because the timestamp counts absolute seconds and the display adds the local offset. Daylight saving makes the trap worse: the same timestamp can fall on different sides of a clock change depending on the year, and a timestamp converted in January may display differently from one converted in July for the same location. The safe habit is to store and log timestamps in UTC, convert to local time only at display, and always label the displayed timezone, because an unlabeled date derived from a timestamp is ambiguous by up to a full day. The second trap is the year 2038 problem: on systems that store timestamps as signed 32-bit integers, the count overflows on January 19, 2038, when it passes 2,147,483,647, and wraps to a negative number, jumping the date back to 1901. Modern 64-bit systems are immune for billions of years, but embedded devices, old databases, and file formats with 32-bit time fields are not, so any system still storing timestamps in 32 bits needs a migration plan before 2038, not in 2038. Both traps share one lesson: a timestamp is exact, but every readable date built from it is a choice of timezone and integer size, and naming those choices is what makes the conversion trustworthy.

How to Tell Seconds, Milliseconds, and Microseconds Apart

How to tell a timestamp unit apart is a length test you can do at a glance. A 10-digit value near 1.7 billion is seconds and lands in the 2020s. A 13-digit value near 1.7 trillion is milliseconds and lands in the same years once divided by 1,000. A 16-digit value near 1.7 quadrillion is microseconds, and a 19-digit value is nanoseconds. The sniff test is to divide until the value is 10 digits and near 1.7 billion: if dividing by 1,000 once gives a sane 2020s date, it was milliseconds, and if dividing by 1,000,000 gives one, it was microseconds. APIs usually document their unit, but logs and database dumps often do not, and mixed units in one dataset are a real hazard: sorting a column that mixes seconds and milliseconds puts all the millisecond rows first, because they are numerically a thousand times larger, and averaging such a column gives nonsense. When you inherit an undocumented timestamp column, convert the first few values by hand with the divide-by-86,400 method, check that the resulting dates fall in a plausible range for the data, and only then trust the column. For the binary side of the same developer toolkit, our text to binary converter handles the encoding questions that sit next to timestamps in most log files, and our markdown to HTML converter covers the documentation step that turns those findings into readable pages. One final check costs nothing and catches the worst errors: convert the same timestamp in two independent ways, by hand and with a converter, and only trust the date when both agree.