Unix Timestamp Converter

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds that have elapsed since 1 January 1970 at 00:00:00 UTC, a moment known as the Unix epoch. It is a single integer, which makes it trivially easy to store, compare, sort, and subtract. Two timestamps subtracted give you a duration in seconds with no calendar arithmetic involved.

One detail catches people out: Unix time does not count leap seconds. When a leap second is inserted, the count effectively repeats or stretches a value rather than advancing past it. This keeps the arithmetic simple (every day is exactly 86,400 seconds) at the cost of not being a true count of elapsed physical seconds.

Seconds vs Milliseconds: the Most Common Date Bug

Different platforms count in different units, and mixing them is one of the most frequent date bugs in production code. The quickest way to tell them apart is digit count: a 10-digit value is seconds, a 13-digit value is milliseconds.

JavaScript is the usual source of the confusion. Date.now() and the Date constructor both work in milliseconds, while most Unix system calls, many database column types, JWT claims such as exp and iat, and a large share of REST APIs use seconds. When you cross that boundary, divide by 1000 and floor, or multiply by 1000, and label the variable with its unit so the next reader does not have to guess.

Reference Timestamps Worth Recognising

Memorising a few landmark values makes it easy to eyeball whether a timestamp in a log file is plausible before you convert it.

The Year 2038 Problem

Older systems store time in a signed 32-bit integer called time_t. The largest value such an integer can hold is 2,147,483,647, which corresponds to 03:14:07 UTC on 19 January 2038. One second later the value overflows and wraps to the most negative integer, interpreted as 13 December 1901. Any code that compares, sorts, or schedules on that value will behave unpredictably.

The fix is straightforward in principle: store time in a signed 64-bit integer, which pushes the limit roughly 292 billion years out. Modern operating systems and language runtimes have largely made that move. The remaining risk sits in embedded devices, old binary file formats, database columns declared as 32-bit integers, and network protocols that pinned the field width. It is worth checking any long-lived schema now rather than in 2037.

Time Zones, and Why Timestamps Avoid a Whole Class of Bugs

A Unix timestamp is always UTC. It carries no time zone, no offset, and no daylight saving information. The zone is applied only when you render the value for a human. That property is exactly why storing timestamps beats storing local date strings: the stored value has one unambiguous meaning, and two servers in different regions will always agree on what it represents.

Store a local string such as "2024-03-10 02:30" instead and you inherit every ambiguity of the calendar. That particular moment does not exist in parts of the United States because clocks jump forward, and an hour in autumn occurs twice. Timestamps have no such gaps or repeats.

ISO 8601

When you do need a human readable form, ISO 8601 is the format to reach for. It writes the date largest unit first, so string sorting matches chronological sorting, and it makes the offset explicit.