What Is a Unix Timestamp and How Do You Read One?

Open almost any log file, database or API response and you will find numbers like 1793610000. That is a Unix timestamp: a moment in time written as one plain number. Computers love it because it is easy to store, sort and subtract. People find it unreadable. This guide shows how the count works, how to read one by hand and the mistakes that make dates jump to 1970 or tens of thousands of years into the future.

A clock that only counts

A Unix timestamp is the number of seconds since 00:00:00 UTC on January 1, 1970, a moment called the Unix epoch. Nothing else is stored: no time zone, no daylight saving flag, no calendar. Each day adds exactly 86,400 seconds (24 × 60 × 60), and leap seconds are ignored.

Because the count is anchored to UTC, the same number means the same instant everywhere. 1793610000 is 09:00 UTC on Monday, November 2, 2026. At that instant it is 04:00 in New York, 12:00 in Istanbul and 18:00 in Tokyo. Only the label on the clock changes.

Milestones worth knowing

Knowing the rough size of a timestamp helps you spot bad data at a glance.

• 1,000,000,000 was reached on September 9, 2001 at 01:46:40 UTC.
• 1,234,567,890 fell on February 13, 2009 at 23:31:30 UTC.
• 1,500,000,000 was July 14, 2017 at 02:40:00 UTC.
• 1,800,000,000 arrives on January 15, 2027 at 08:00:00 UTC.
• 2,000,000,000 arrives on May 18, 2033 at 03:33:20 UTC.
• 2,147,483,647, the largest signed 32-bit number, is January 19, 2038 at 03:14:07 UTC.

So a 10-digit timestamp starting with 17 or 18 is a date in the mid-2020s, and a 9-digit one is from before September 2001.

How to read a timestamp by hand

You will rarely need to, but doing it once makes the idea concrete. Take 1793610000.

1. Split off whole days. 1,793,610,000 ÷ 86,400 = 20,759.375, so 20,759 full days have passed since the epoch.
2. Turn the leftover into a time. 0.375 of a day is 0.375 × 86,400 = 32,400 seconds, which is exactly 9 hours. The time is 09:00:00 UTC.
3. Count the days forward from January 1, 1970. 20,759 days later is November 2, 2026. This is the step to leave to software, because of leap years.

To go the other way, count the days from the epoch to your date, multiply by 86,400 and add the seconds since midnight UTC. January 1, 2027 is 20,819 days after the epoch, and 20,819 × 86,400 = 1,798,761,600.

Seconds, milliseconds and the wrong-date bug

Unix time is traditionally in seconds, but JavaScript, Java and many web APIs use milliseconds. The two differ by a factor of 1,000, and mixing them up is the most common timestamp bug of all.

• Read the millisecond value 1,798,761,600,000 as seconds and you get a date more than 55,000 years in the future, which most date tools refuse to show.
• Read the second value 1,798,761,600 as milliseconds and you get January 21, 1970 at 19:39:21.600 UTC. A date that shows up in January 1970 is almost always this mistake.

The quick check is to count digits. For present-day dates, seconds have 10 digits and milliseconds have 13. You will also meet microseconds (16 digits) and nanoseconds (19 digits) in databases and tracing tools.

Local time is where the trouble starts

A timestamp has no time zone, but a date typed into a form does. "November 2, 2026, 09:00" is a different instant in Tokyo and in New York, 14 hours apart. Whenever you turn a date into a timestamp, you have to decide whose clock it is.

Two practical rules:

• Store and send UTC timestamps, and convert to local time only for display. Nobody then has to guess which zone a value belongs to.
• Take care around daylight saving changes. When clocks jump forward, one local hour does not exist; when they fall back, one hour happens twice. The timestamp is never ambiguous, but the local time you start from may be.

ISO 8601 text such as 2026-11-02T09:00:00Z is a readable alternative. The trailing Z means UTC; an offset such as +03:00 means the clock was three hours ahead of UTC. Many APIs accept both forms.

Doing arithmetic with timestamps

This is where Unix time shines. Durations are just subtraction:

• 1,798,761,600 − 1,793,610,000 = 5,151,600 seconds between 09:00 UTC on November 2, 2026 and New Year 2027. Divided by 86,400 that is 59.625 days, or 59 days and 15 hours.
• Adding 7 × 86,400 = 604,800 moves a timestamp exactly one week forward.

One caveat: "one day later" in local time is not always 86,400 seconds, because a day with a daylight saving change lasts 23 or 25 hours. For calendar math in local time, use a date library rather than raw seconds.

How to use the Unix Timestamp Converter

Paste a timestamp into the Unix Timestamp Converter and it shows the moment in UTC, in your own time zone and as ISO 8601, with the value in both seconds and milliseconds. Leave the unit on automatic and it decides between seconds and milliseconds from the size of the number, or set the unit yourself for unusual values. The second panel works the other way: pick a date and time, say whether it is local time or UTC, and copy the timestamp. A live counter shows the current Unix time, which is handy when you compare log entries with the present.

FAQ

Why does Unix time start in 1970?

It was a convenient round date for the early Unix developers. There is nothing special about the moment itself; any fixed starting point would work, and some other systems use different ones.

How do I convert a timestamp in a spreadsheet?

Spreadsheets count days, not seconds, from their own start date. In Excel and Google Sheets, divide the seconds by 86,400 and add 25,569, the day number of January 1, 1970: =A1/86400+25569. Then format the cell as a date and time. The result is in UTC.

Will the 2038 problem affect me?

Most current phones, computers and servers use 64-bit time and will be fine. The risk lies in older embedded devices, file formats and databases that still store time in 32 bits. If you look after such a system, test it with dates after January 19, 2038.

Are two events with the same timestamp simultaneous?

Only to the precision stored. A timestamp in seconds cannot separate two events within the same second, which is one reason logs and databases often use milliseconds or finer.