A Unix timestamp is a single number that identifies one moment in time: the count of seconds that have elapsed since 00:00:00 UTC on 1 January 1970. That starting instant is called the Unix epoch. When you see a number like 1780000000 in a database or an API response, you are looking at a Unix timestamp.
The idea came out of the early Unix operating system at Bell Labs in the early 1970s. Storing time as one integer made comparing, sorting and arithmetic on dates trivially easy for computers, and the convention spread until it became the default way software thinks about time.
Why computers love a single number
Human-readable dates are messy: they have time zones, daylight saving shifts, leap years, different calendars and a dozen written formats. A Unix timestamp has none of that. It is the same number in Tokyo and in Toronto, it never repeats, and subtracting two timestamps gives the exact number of seconds between them. That is why servers, logs and databases almost always store timestamps internally and convert to local time only when displaying to a person.
- 0 = midnight UTC, 1 January 1970 (the epoch).
- 86400 = one day later, because a day has 86,400 seconds.
- Negative numbers represent moments before 1970.
Seconds, milliseconds and beyond
The classic timestamp counts whole seconds, but modern systems often need finer detail. JavaScript's Date.now() returns milliseconds since the epoch — the same number with three extra digits. Some databases use microseconds or nanoseconds. When a timestamp looks "wrong" by a factor of a thousand, a seconds-versus-milliseconds mix-up is almost always the cause.
The year 2038 problem
Older systems store the timestamp as a signed 32-bit integer, which maxes out at 2,147,483,647 — 03:14:07 UTC on 19 January 2038. One second later, those systems wrap around to a negative number and think it is 1901. It is the same class of bug as the Y2K problem, and it is being fixed the same way: by moving to 64-bit integers, which will not overflow for roughly 292 billion years.
Timestamps and leap seconds
Unix time deliberately pretends leap seconds do not exist: every day is treated as exactly 86,400 seconds, even on days when a leap second is inserted. Systems that need the true physical duration handle leap seconds separately. For everyday purposes the simplification is harmless, but it is why a timestamp difference across a leap-second boundary can be off by a second.
Curious what the current epoch time looks like as a clock? Our live world clock is driven by exactly this number, converted into your local zone using the rules described in our guide to UTC.