# Unix time: the number that counts seconds since 1970

> Developers store dates as a single number like 1700000000. It looks cryptic, but it is just a stopwatch started at midnight on 1 January 1970. Here is how to read it, why it has 10 or 13 digits, and what happens in 2038.

Published 2026-10-08 by Toolcloak. 3 minute read. Original: https://toolcloak.pages.dev/articles/unix-time-the-number-that-counts-seconds-since-1970
Related free tool: [Timestamp Converter](https://toolcloak.pages.dev/tools/timestamp-converter)

You open a database and a column says `1700000000`. It is a date. It means **14 November 2023, 22:13:20 UTC**. Once you know the trick, reading these takes no effort, and the 13-digit versions stop being scary too.

> **In short**
> - Unix time counts seconds since 1 January 1970, 00:00:00 UTC. No time zone is stored.
> - 10 digits means seconds, 13 digits means milliseconds.
> - A signed 32-bit counter overflows on 19 January 2038. Modern 64-bit systems are fine.

Unix time, also called epoch time, is the way most software counts time. It is the number of **seconds** that have passed since 00:00:00 UTC on 1 January 1970, a moment called the epoch. There are no months, no time zones and no daylight saving in it. Just a number that goes up by one every second.

## Why a single number is so handy

- **Easy to compare.** The bigger number is later. No need to parse “3rd Oct” against “10/03/26”.
- **Easy to subtract.** The gap between two moments is just one number minus the other, in seconds.
- **Same everywhere.** A timestamp means the same instant in Mumbai, London and Tokyo. Only how you display it changes.
- **Tiny to store.** One integer instead of a text string with a format everyone has to agree on.

Try it: [Timestamp Converter](https://toolcloak.pages.dev/tools/timestamp-converter). Paste a timestamp to see the date in UTC, ISO format and your own time zone, or pick a date to get its timestamp.

## A few famous numbers

**Moments on the Unix clock**

| When | What |
| --- | --- |
| 0 | 1 January 1970, 00:00:00 UTC. The epoch. Every Unix timestamp counts from here. |
| 1,000,000,000 | 9 September 2001, 01:46:40 UTC. The clock’s billionth second. Programmers celebrated. |
| 1,700,000,000 | 14 November 2023, 22:13:20 UTC. In India this is already 15 November, 03:43:20. |
| 2,147,483,647 | 19 January 2038, 03:14:07 UTC. The largest value a signed 32-bit number can hold. |
| 4,294,967,295 | 7 February 2106, 06:28:15 UTC. The limit if the number is unsigned 32-bit instead. |

*Every number on the left is a count of seconds. The gap from 1970 to 2038 is a little over 68 years.*

## Seconds, or milliseconds?

The classic Unix timestamp is in seconds and has **10 digits** for any date between 2001 and 2286. JavaScript and many modern systems use **milliseconds**, which makes the number 1000 times larger, so it has **13 digits**.

| Unit | Example for the same moment | Digits |
| --- | --- | --- |
| Seconds | `1700000000` | 10 |
| Milliseconds | `1700000000000` | 13 |
| Microseconds | `1700000000000000` | 16 |

*Same instant, same date: 14 November 2023, 22:13:20 UTC. If a converter shows a date in January 1970 or a year past 50,000, you picked the wrong unit.*

> **Quick check:** Count the digits. **10 digits** means seconds. **13 digits** means milliseconds. If you feed a millisecond value to a tool expecting seconds you get a date tens of thousands of years in the future.

## The time zone is only in the display

The timestamp is the same for everyone on Earth. When you convert it into a readable date you choose a time zone. The same `1700000000` is 22:13 in London and Reykjavik (UTC), 03:43 the next morning in India (UTC+5:30), and 07:13 the next morning in Tokyo (UTC+9).

This is also why bugs appear around midnight and around daylight saving changes: the stored number is perfect, but a program displays it with the wrong zone. When something looks off by a few hours, suspect the display, not the data.

## A day is always 86,400 seconds

**Handy constants**

|  | Value | Note |
| --- | --- | --- |
| Seconds in a minute | 60 |  |
| Seconds in an hour | 3,600 | 60 × 60 |
| Seconds in a day | 86,400 | 24 × 3,600 |
| Seconds in a normal year | 31,536,000 | 365 × 86,400 |

*To get tomorrow at this time, add 86,400 to the timestamp. Unix time ignores leap seconds and treats every day as exactly this long.*

That makes simple jobs easy. “One week from now” is the current timestamp plus 604,800. “Thirty days ago” is minus 2,592,000. The tricky parts, like calendar months with different lengths, are where a real date library earns its keep.

## The year 2038 problem

Older systems stored the timestamp in a signed 32-bit integer. The biggest value that fits is 2,147,483,647, and one second later it wraps around to a large negative number, which a computer would read as December 1901. The moment of that overflow is **19 January 2038 at 03:14:07 UTC**.

Most modern software uses 64 bits, which lasts for hundreds of billions of years, so the problem is mostly solved on new systems. It still matters for old embedded devices and code that stores dates in 32-bit fields, and it is the reason people test their systems with dates past 2038.

## Frequently asked questions

### What is a Unix timestamp?

The number of seconds since 00:00:00 UTC on 1 January 1970. It identifies one exact moment independent of any time zone.

### How can I tell if a timestamp is in seconds or milliseconds?

Count digits. Ten digits is seconds, thirteen is milliseconds, for dates in the current era.

### Does a Unix timestamp include a time zone?

No. It always refers to UTC. A time zone only comes into play when you convert the number into a readable local date.

### What is the year 2038 problem?

Systems storing Unix time in a signed 32-bit number overflow on 19 January 2038 at 03:14:07 UTC. Modern 64-bit systems are not affected.

### How do I convert a date to a timestamp?

Count the seconds from 1 January 1970 UTC to your date, or use a converter. The timestamp for 8 October 2026 at 00:00 UTC is 1791417600.