Unix timestamp to date converter

What is a Unix timestamp?

A Unix timestamp, also called Unix time or POSIX time, is the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, known as the Unix epoch. It is a widely used standard in computing because it represents a point in time as a single integer, which makes storage, comparison, and arithmetic straightforward.

JavaScript works internally in milliseconds, so Date.now() returns the Unix timestamp multiplied by 1000. Many APIs, databases, and backend systems use seconds instead. This tool accepts either format and detects seconds or milliseconds automatically based on the size of the number you enter.

Notable Unix timestamps

Why 1970?

The Unix epoch of January 1, 1970 was chosen partly by convention and partly by practical constraints. Unix was developed in the late 1960s and early 1970s at Bell Labs. The developers needed a recent, round starting date for their time representation. January 1, 1970 was recent enough to be practical and had no special technical significance — it was simply a convenient anchor point.

Alternative epoch dates exist in other systems: the Windows FILETIME epoch is January 1, 1601; GPS time started January 6, 1980; the NTP epoch is January 1, 1900. When converting between systems, knowing each system's epoch is essential.

Seconds vs milliseconds

The original Unix timestamp is in seconds. Most server-side languages and systems (Unix shell, Python's time.time(), PHP's time(), most databases) use seconds. JavaScript's Date.now() and new Date().getTime() return milliseconds. This mismatch is a common source of bugs when JavaScript frontends communicate with backend APIs.

A Unix timestamp in seconds is currently a 10-digit number (around 1,700,000,000 as of 2023). A millisecond timestamp is a 13-digit number. The calculator detects which format you have entered based on the number of digits and converts accordingly.

The Year 2038 problem

Systems that store Unix timestamps as a signed 32-bit integer can only represent dates up to 2,147,483,647 seconds after the epoch — which is 03:14:07 UTC on January 19, 2038. After that moment, a 32-bit signed integer overflows to a large negative number, representing a date in 1901.

This is sometimes called the "Y2K38" problem or the Unix Millennium Bug. Modern 64-bit systems are not affected, as a signed 64-bit integer can represent timestamps for approximately 292 billion years. However, embedded systems, legacy databases, and older 32-bit software may still be vulnerable. Many industries — including telecommunications, banking, and industrial control systems — have ongoing migration efforts to address this.

How to get the current Unix timestamp

Practical uses

API development: REST APIs commonly use Unix timestamps for created_at, updated_at, and token expiry fields. A timestamp is timezone-agnostic and unambiguous — unlike formatted date strings, which depend on locale and formatting conventions.

Token expiry: JWT (JSON Web Tokens) use Unix timestamps for the exp (expiry) and iat (issued at) claims. A token expires when the current timestamp exceeds the exp value. Calculating expiry times — "this token should expire in 24 hours" — requires adding 86,400 seconds to the current timestamp.

Cache TTL: Cache expiry is often set as a Unix timestamp or as a number of seconds from now. Debugging cache issues frequently requires converting a stored expiry timestamp to a human-readable date.

Log analysis: Server logs often include Unix timestamps. Converting them to readable dates is the first step in correlating log entries with real-world events.

Database storage: Storing timestamps as integers rather than formatted strings avoids timezone conversion bugs and simplifies sorting, range queries, and arithmetic. A query for "all records from the last 7 days" becomes WHERE created_at > (NOW_UNIX - 604800).