Unix time: the number that counts seconds since 1970

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.

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.

A few famous numbers

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.

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

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.