Epoch/Unix Converter
Convert Unix timestamps to human-readable dates and back. Essential for debugging APIs and logs.
What it's for
Unix timestamps instantly
Seconds and milliseconds
Automatically detects whether the timestamp is in seconds (10 digits) or milliseconds (13 digits).
100% private
Conversion happens in your browser using JavaScript's native Date API. No servers involved.
Multiple formats
Shows the result in ISO 8601, UTC, local date, and relative format (X days ago).
Instant
Conversion is immediate. Also shows the current timestamp updating in real time.
How it works
Three steps, no hassle
Enter the timestamp or date
Paste a Unix timestamp (in seconds or milliseconds) or enter a date in ISO 8601 format to convert in the opposite direction.
Select the timezone
Choose your timezone or UTC to see the correct local date. Unix timestamps are always UTC internally.
Copy the result
Get the formatted date in multiple formats (ISO 8601, UTC, local) or the numeric timestamp. One click to copy.
FAQ
Got questions?
The Unix epoch (also called Unix time or POSIX time) is the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC, excluding leap seconds. This reference date was chosen because Unix was developed in the late 1960s and a convenient starting point was needed. Unix time is continuous, uniform, and timezone-independent, making it ideal for storing and comparing instants in distributed systems.
Classic Unix systems (C, Python datetime, SQL databases) use seconds. JavaScript/Node.js environments, Java (System.currentTimeMillis()), and many modern APIs use milliseconds. A timestamp in seconds has 10 digits (e.g., 1704067200 for January 1, 2024), while in milliseconds it has 13 digits (1704067200000). Some systems use microseconds (16 digits) or nanoseconds (19 digits) for high-precision measurements.
The Y2K38 problem (also called the Year 2038 problem or Unix Millennium Bug) will occur on January 19, 2038 at 03:14:07 UTC. At that moment, the Unix timestamp stored as a 32-bit signed integer (int32) will reach its maximum value (2,147,483,647) and overflow, wrapping back to a negative number that systems will interpret as December 13, 1901. Systems using int64 (64-bit integers) will not face this problem until the year 292,277,026,596.
Unix timestamps have clear technical advantages over formatted dates: they are a simple number (easy to compare, sort, and serialize), have no timezone ambiguity (they always represent the same UTC instant), have no format ambiguity (MM/DD/YYYY vs DD/MM/YYYY), take less space (8 bytes as int64 versus 24+ bytes as an ISO string), and are more efficient for range operations on database indexes.
Unix timestamps are always UTC — they represent the same instant regardless of where you are. The timezone only matters when converting a timestamp to a human-readable representation (local date and time) or when creating a timestamp from a local date. A common mistake is ignoring the timezone when parsing dates and assuming local time: this causes errors of ±N hours depending on the system's timezone offset, which are hard to detect because tests usually run in UTC.
Unix time: the universal clock of computer systems
Unix time is the de facto standard for representing temporal instants in computer systems. Its elegance lies in its simplicity: a single integer that grows monotonically, with no ambiguity of format, timezone, or calendar. It was defined in the POSIX specification and adopted by all Unix-derived operating systems (Linux, macOS, BSD) and most modern programming languages. POSIX.1-2008 formally defines it as the number of seconds since the Unix epoch, with the notable quirk that leap seconds are not counted.
In the database ecosystem, Unix timestamps are ubiquitous. PostgreSQL has the TIMESTAMP type which internally stores microseconds since the Unix epoch. MySQL provides UNIX_TIMESTAMP() and FROM_UNIXTIME() functions. MongoDB stores dates as milliseconds since the epoch in its Date type. Redis uses Unix timestamps for key expiration (EXPIREAT). System logs from Apache, Nginx, and syslog frequently include Unix timestamps to facilitate processing with tools like awk, grep, and shell scripts.
The Y2K38 problem is the modern equivalent of the original Y2K: systems that store timestamps as signed int32 will overflow on January 19, 2038. While most modern systems already use int64, the problem persists in embedded systems, old firmware, and legacy code. Migrating to int64 is the standard solution. Convertir.ai shows how much time remains until Y2K38 and allows you to verify whether a specific timestamp falls before or after that critical date.