Unix Time Explained

At midnight UTC on September 27, 2026, the Unix clock read 1,790,467,200. That single number is how most servers, phones, and databases store the moment. It counts the seconds since the first instant of 1970, with no months, time zones, or daylight saving mixed in. Here is how to read it, check it by hand, and avoid its traps.

What Does a Unix Timestamp Actually Count?

A Unix timestamp counts the seconds that have passed since the epoch, 00:00:00 UTC on January 1, 1970. The POSIX standard defines that epoch, and it calls the count “seconds since the Epoch.”

So the value 0 is the epoch itself. The value 60 is one minute later, and 3,600 is one hour later. The value 1,000,000,000 landed at 01:46:40 UTC on September 9, 2001.

The count keeps climbing by one every second. Programs love it because comparing two moments becomes simple subtraction. For example, a log line stamped 1,700,003,600 happened exactly 3,600 seconds, or one hour, after one stamped 1,700,000,000.

You will also see the names epoch time and POSIX time. All three names describe the same count.

A plain number also sorts perfectly. Ordering a million log lines by time takes one numeric sort, with no date parsing at all. Durations work the same way, since a week is always 604,800 seconds in Unix time.

Can You Decode 1,700,000,000 With Pencil and Paper?

Yes. Divide the timestamp by 86,400, the seconds in one day. The whole-number part counts days since the epoch, and the remainder gives the time of day.

Take 1,700,000,000, the example on our Unix timestamp converter page. Dividing by 86,400 gives 19,675 full days with 80,000 seconds left over.

Now turn 80,000 seconds into a clock time. That is 22 hours (79,200 seconds), then 13 minutes (780 seconds), then 20 seconds. Counting 19,675 days forward from January 1, 1970 lands on November 14, 2023.

The answer is Tuesday, November 14, 2023, at 22:13:20 UTC. In ISO 8601 form, that reads 2023-11-14T22:13:20Z, where the Z marks a UTC offset of zero.

The day count is the slow step, because months and years have different lengths. POSIX handles it with a formula that adds a day every fourth year, then drops or restores century days. That matches the calendar rule in our guide to how leap years work.

Where Do Leap Seconds Go in Unix Time?

Nowhere. POSIX says every day is counted as exactly 86,400 seconds, so a leap second never gets its own Unix number. The count simply skips over it.

Leap seconds are real, though. NIST explains that they began in 1972 and are added on the last second of June or December. On those nights, a UTC clock reads 23:59:59, then 23:59:60, then 00:00:00.

Unix time has no slot for 23:59:60. POSIX leaves the exact handling to each system, calling the adjustment “implementation-defined.” As a result, subtracting two timestamps across a leap second gives one second less than the true elapsed time.

For most tasks, this gap does not matter. A timestamp still maps to one clear UTC date and time. It matters for work that measures exact intervals, such as scientific logging or network timing across a leap second.

Is That Timestamp in Seconds or Milliseconds?

Count the digits. A current timestamp in seconds has 10 digits, and the same moment in milliseconds has 13 digits. The millisecond value is exactly 1,000 times larger.

For example, 1700000000 and 1700000000000 describe the same instant in November 2023. JavaScript dates store milliseconds since the epoch. POSIX systems, by contrast, count whole seconds.

The 10-digit rule has limits worth knowing. Seconds values stayed at 9 digits until 01:46:39 UTC on September 9, 2001. They will keep 10 digits until 17:46:39 UTC on November 20, 2286.

Mixing the two units causes wild errors. Reading a millisecond value as seconds throws the date tens of thousands of years into the future. Reading seconds as milliseconds lands you in January 1970. The converter guards against the first mistake by treating any value of 100,000,000,000 or more as milliseconds.

Why Does One Timestamp Show Three Different Clock Times?

A Unix timestamp marks one instant for the whole planet. Time zones only enter when software turns that number into a local clock reading on a screen.

Take 1,700,000,000 again. In UTC it reads 22:13:20 on November 14, 2023. In Tokyo, at UTC+9, the same instant shows 07:13:20 on November 15. In India, at UTC+5:30, it shows 03:43:20 on November 15.

Notice that two of the three readings fall on a different date. That is why you should store the raw timestamp and convert only at display time. Daylight saving changes the displayed hour, but it never changes the stored number.

Working out offsets by hand has its own traps, like half-hour zones and date-line jumps. Our guide to time zone calculation covers those in detail.

One practical habit helps a lot. When you log an event, save the timestamp and the viewer’s zone name as separate fields. That way, you can always rebuild the local time later without guessing.

What Breaks When 32-Bit Clocks Hit January 2038?

A signed 32-bit number tops out at 2,147,483,647. As a Unix timestamp, that is 03:14:07 UTC on Tuesday, January 19, 2038. One second later, the count cannot fit.

In standard signed storage, adding one more second wraps the value to -2,147,483,648. Read as a date, that lands at 20:45:52 UTC on December 13, 1901. A device with this flaw would suddenly believe it is 136 years in the past.

The fix is a wider number. A signed 64-bit count lasts about 292 billion years, far beyond any practical need. POSIX only says the time type must be an arithmetic type of suitable length, so the width depends on the system.

Older embedded devices, file formats, and database columns carry the most risk. An unsigned 32-bit count lasts longer, to 06:28:15 UTC on February 7, 2106, but it cannot store dates before 1970.

Future dates reach the limit first. A program that schedules events 15 years ahead already handles dates past 2038 today.

FAQs About Unix Time

Sources

This article explains how Unix time counts and displays moments. System behavior at leap seconds and in 2038 varies, so check your own platform’s documentation. Reviewed for accuracy by Prof. Dr. Khalil Mudassar, PhD. Last updated September 27, 2026.