What Is a Unix Timestamp? Epoch Time Explained

A Unix timestamp is a single number that represents a moment in time as the count of seconds that have elapsed since a fixed starting point. That starting point - midnight on 1 January 1970, in Coordinated Universal Time (UTC) - is called the Unix epoch, which is why the value is also known as epoch time or POSIX time. Instead of juggling years, months, days, hours and timezones, a computer can store any instant as one plain integer. This guide explains what a Unix timestamp is, why it is so widely used, the difference between seconds and milliseconds, why it is always in UTC, and the famous Year 2038 problem.

The Unix epoch: zero seconds

By definition, the timestamp 0 is exactly midnight (00:00:00) UTC on 1 January 1970. Every moment after that is a positive number of seconds, and every moment before it is a negative number. So a timestamp of 60 is one minute past the epoch, 3600 is one hour past it, and 86400 - the number of seconds in a day - is midnight on 2 January 1970. This single, agreed reference point is what lets two machines anywhere in the world describe the same instant with the same number.

Why computers count time this way

Storing time as one integer is enormously convenient. Comparing two moments becomes simple arithmetic - the later instant is just the larger number - and finding the gap between two events is a subtraction. There are no month lengths, leap-year rules or timezone offsets to reason about while doing the maths. Timestamps sort naturally, take very little space, and are unambiguous, which is why they appear throughout computing:

• Databases store created-at and updated-at columns as timestamps.
• Log files and events are stamped with epoch time so they sort in order.
• JSON Web Tokens (JWTs) express their iat (issued-at) and exp (expiry) claims as Unix timestamps - see What's Inside a JWT?.
• File systems, version control and APIs use them to record exactly when something happened.

A worked example

Take the timestamp 1700000000. To read it, you work out how far it is from the epoch. That value lands on Tuesday, 14 November 2023 at 22:13:20 UTC. You can confirm it instantly by pasting 1700000000 into the Unix Timestamp Converter, which shows the moment in UTC, your own local time, and the ISO 8601 format all at once.

The conversion the other way works just as well: give the converter a date and it returns the matching integer. Because the number is just a count of seconds, adding 86400 to any timestamp moves it forward exactly one day, and subtracting 3600 moves it back one hour - no calendar logic required.

Seconds vs milliseconds

Here is the detail that trips people up most often. The classic Unix timestamp counts seconds, but many programming environments - JavaScript most notably - count milliseconds (thousandths of a second) instead. The same instant therefore has two common representations:

• In seconds: 1700000000
• In milliseconds: 1700000000000

The millisecond value is simply the second value multiplied by 1,000, so it has three extra digits. If a timestamp ever decodes to a date far in the distant future - thousands of years away - you have almost certainly fed a milliseconds value into something expecting seconds, or vice versa. A quick way to tell them apart today: a seconds timestamp for a recent date has 10 digits, while a milliseconds timestamp has 13. The Unix Timestamp Converter detects which unit you have entered from its size, so you do not have to guess.

Unix time is always UTC

A Unix timestamp has no timezone of its own - it always refers to UTC. This is a feature, not a limitation. The number 1700000000 means the very same instant whether it is read in Tokyo, London or New York; only the human-readable wall-clock time differs once you apply a local timezone offset. That is exactly why systems store the timestamp and convert to local time only for display: it removes any ambiguity about which moment is meant. When you see a timestamp turned into a date, the conversion to your local time happens at the moment of display, not in the stored value itself.

It is worth noting that Unix time also ignores leap seconds - the occasional one-second adjustments made to civil time. It assumes every day is exactly 86,400 seconds long, which keeps the arithmetic clean at the cost of not tracking those rare corrections precisely. For almost all everyday purposes this simplification is invisible and harmless.

The Year 2038 problem

Many older systems store Unix timestamps in a signed 32-bit integer, which can hold a maximum value of 2,147,483,647. Count that many seconds from the epoch and you arrive at 03:14:07 UTC on 19 January 2038. One second later, the counter overflows and wraps around to a large negative number, which those systems would interpret as a date back in December 1901. This is the Year 2038 problem - the modern echo of the Year 2000 bug.

The fix is already widespread: moving to 64-bit integers for time, which pushes the overflow point hundreds of billions of years into the future - far longer than the age of the universe. Most current operating systems, languages and databases have made this switch, so the risk now sits mainly with old embedded devices and legacy code that still use 32-bit time and have not been updated.

Negative timestamps and dates before 1970

Because the epoch is a fixed midpoint rather than the beginning of time, dates before 1 January 1970 are perfectly valid - they are simply negative timestamps. A value of -86400 is one day before the epoch, 31 December 1969, and larger negative numbers reach further back. Not every tool or language supports negative timestamps equally well, so historical dates are sometimes handled by other means, but conceptually the number line of Unix time extends in both directions from zero.

Reading and creating timestamps

Whenever you meet a bare number where a date should be - in a log line, an API response, a database row or a decoded token - the quickest way to make sense of it is to convert it. Drop the value into the Unix Timestamp Converter to see the UTC time, your local time and the ISO 8601 string side by side, and use the same tool in reverse to turn a calendar date into the integer a system expects. Once you are comfortable that it is just a count of seconds from a fixed point, epoch time stops looking cryptic and becomes one of the simplest, most reliable ways to handle time in software.