What Is Unix Time (Epoch Time)?

Why computers count time this way

Dates are awkward for software. Months have different lengths, time zones shift, and daylight saving time moves the clocks twice a year. A single growing number avoids all of that. To find out how long passed between two events, subtract one timestamp from the other. To sort events, sort the numbers.

The early Unix operating system at Bell Labs settled on 1 January 1970 as its starting point, and the convention spread to almost every system since: Linux, macOS, Android, databases, web servers and most programming languages.

Reading a timestamp: 10 digits or 13?

A Unix timestamp in seconds currently has 10 digits, for example 1791504000. Many systems, including JavaScript and Java, use milliseconds instead, which adds three digits: 1791504000000. If a timestamp turns into a date in the year 58,000 or in January 1970, it is almost certainly in the wrong unit.

Negative timestamps are valid and mean dates before 1970. −86,400 is 31 December 1969.

Getting the current Unix time

• Linux or macOS terminal: date +%s
• JavaScript: Math.floor(Date.now() / 1000) for seconds, or Date.now() for milliseconds
• Python: import time; int(time.time())
• PHP: time()
• SQL (PostgreSQL): SELECT EXTRACT(EPOCH FROM now());

Or open the Unix timestamp converter, which shows the live timestamp and converts in both directions in your own time zone.

Time zones and Unix time

A Unix timestamp has no time zone. It marks one instant, and that instant is the same everywhere. The time zone only matters when you turn it into a date for a person to read. 1800000000 is 15 January 2027 at 08:00 UTC, which is 03:00 in New York and 13:30 in India, all at the same moment.

This is why developers store timestamps (or UTC dates) and convert to local time only for display. If you need to compare clocks between cities, the time zone converter does that, and our guide to GMT vs UTC explains the reference everything is measured from.

Leap seconds: the one quirk

Unix time pretends every day is exactly 86,400 seconds. When a leap second was added to UTC, Unix clocks either repeated a second or smeared the extra second across several hours. The practical effect is that subtracting two timestamps can be out by the number of leap seconds between them, at most 27. For almost any everyday purpose that does not matter, and no leap second has been added since 2016.

Converting a timestamp by hand

You rarely need to, but it shows how simple the format is. Take 1,800,000,000. Divide by 86,400 to get days since 1970: 20,833 whole days, with 28,800 seconds left over. 28,800 seconds is 8 hours, so the time is 08:00 UTC. Counting 20,833 days forward from 1 January 1970, allowing for leap years, lands on 15 January 2027.

Going the other way is the same in reverse: count the days from 1 January 1970 to your date, multiply by 86,400 and add the seconds since midnight UTC. In practice, a converter or a single line of code is faster and avoids leap-year slips.

Common Unix time mistakes

• Mixing seconds and milliseconds. Passing a 10-digit value to JavaScript's Date gives a date in January 1970; passing 13 digits to a function expecting seconds gives a date tens of thousands of years away.
• Treating local time as UTC. If you build a timestamp from a local date without stating the time zone, it can be off by your UTC offset, and by an extra hour around daylight saving changes.
• Storing timestamps as text. Strings sort and compare differently from numbers. Store them in an integer or a proper date-time column.
• Assuming every day is the same in local time. A day is always 86,400 Unix seconds, but a local calendar day can be 23 or 25 hours long when the clocks change.
• Using 32-bit fields for future dates. Anything after January 2038 needs 64-bit storage.

When debugging, paste the suspect value into the Unix timestamp converter. If the date looks wrong by a round number of hours, it is a time zone problem; if it is wrong by decades or millennia, it is a seconds-versus-milliseconds problem.

The year 2038 problem

Older systems store Unix time as a signed 32-bit integer, whose largest value is 2,147,483,647. That number is reached at 03:14:07 UTC on 19 January 2038. One second later, a 32-bit counter overflows to a large negative number and the date jumps back to December 1901.

Modern operating systems and languages use 64-bit time, which will not overflow for about 292 billion years, so most computers and phones are already fine. The risk is in old embedded devices, file formats and databases that still use 32-bit fields. If you maintain software that stores dates far in the future, such as 30-year loans or certificates, it is worth checking now.

Frequently asked questions

Related guides

• GMT vs UTC: What Is the Difference?
• How Many Seconds Are in a Year? Every Unit, Worked Out

See all guides.