Unix Timestamp Converter (Epoch ⇄ Date)
Inputs
| Conversion direction | Epoch → Date |
|---|---|
| Unix timestamp | 1,784,550,784 |
| Timestamp unit | Seconds |
| Date | Jul 20, 2026 |
Unix Timestamp Converter (Epoch ⇄ Date)
Convert a Unix timestamp (epoch) to a human-readable UTC date and ISO 8601 string, or convert any calendar date back to its epoch value in seconds and milliseconds.
Inputs
Input
Results
Enter a value to see results.
Result
Unix Timestamp (Epoch ⇄ Date)
A Unix timestamp is an integer that counts the number of seconds elapsed since 1970-01-01 00:00:00 Coordinated Universal Time (UTC). Software systems use it as a compact, unambiguous representation of any instant in time, independent of local time zones or calendar conventions. This calculator converts between a numeric epoch value and a human-readable UTC date — in both directions.
What the Unix epoch is and where it came from
The starting point, 1970-01-01 00:00:00 UTC, is an artifact of early Unix development. When the Bell Labs team was writing the original Unix kernel in the late 1960s, they needed a fixed reference for time calculations. The exact choice was arbitrary; what mattered was that it be consistent across all machines running the system. The convention spread to POSIX and from there to virtually every operating system and programming language in use today.
A timestamp of 0 represents the epoch itself. A timestamp of 86,400 represents exactly one day later (60 seconds × 60 minutes × 24 hours). Negative timestamps represent moments before 1970, which is valid — most modern implementations can represent dates stretching back thousands of years.
Seconds versus milliseconds
The original Unix standard counts whole seconds. Most of the Unix world — server log files, database records, shell utilities — still uses second-precision timestamps, producing 10-digit values for dates in the 2000s and 2030s.
JavaScript introduced a millisecond-precision variant: Date.now() and Date.getTime() return the number of milliseconds since the epoch, producing 13-digit values. Many REST APIs, event streams, and JavaScript-adjacent databases follow this convention.
The practical rule: a 10-digit number is almost certainly seconds; a 13-digit number is almost certainly milliseconds. To convert milliseconds to seconds, divide by 1,000 — this calculator does that automatically when you select the milliseconds unit.
How the conversion works
Epoch to date. Given a timestamp in seconds, the UTC date and time is determined by:
daystime of day=⌊86,400t⌋=tmod86,400The day count is then mapped to a proleptic Gregorian calendar date by accounting for leap years. The time of day is split into hours, minutes, and seconds by successive modular division.
Date to epoch. Given a calendar date at UTC midnight, the epoch is computed by counting the number of days from 1970-01-01 and multiplying by 86,400. For a date such as 2024-01-01, the day count is 19,723 (10,957 days from 1970 through 1999, plus 8,766 days from 2000 through 2023), giving an epoch of:
This calculator uses the standard JavaScript Date API and registered helper functions to handle leap years and calendar edge cases precisely.
The Year 2038 problem
Many legacy systems store Unix timestamps as a 32-bit signed integer. The largest value a 32-bit signed integer can hold is 2,147,483,647, which corresponds to 2038-01-19 03:14:07 UTC. After that instant the counter wraps around to the most negative 32-bit value, causing those systems to interpret the date as 1901-12-13.
Modern 64-bit systems are not affected. A 64-bit signed integer can represent timestamps ranging from roughly 292 billion years in the past to 292 billion years in the future — well beyond any practical concern. The Year 2038 problem is therefore a legacy-software issue, not a fundamental limitation of the Unix epoch concept. Most mainstream operating systems, databases, and programming languages moved to 64-bit time storage before 2020.
Common pitfalls
Time zones. A Unix timestamp always counts seconds from UTC midnight on 1970-01-01. It does not encode a time zone. When converting a local time to an epoch, you must first convert the local time to UTC. This calculator converts dates using UTC midnight, which is the standard interpretation for date-only inputs.
Leap seconds. The Unix epoch does not account for leap seconds — it assumes exactly 86,400 seconds in every day. As a result, Unix timestamps are not strictly equivalent to International Atomic Time (TAI) or to the elapsed second count maintained by precision timing authorities. For everyday software purposes this discrepancy (37 seconds cumulative as of 2024, unchanged since the last leap second in January 2017) is irrelevant.
Integer overflow in older code. Even if the host OS uses 64-bit time, third-party libraries, database column types, or serialization formats may store timestamps as 32-bit integers. When writing to or reading from external systems, verify the storage width if precision around or beyond 2038 matters.
Frequently Asked Questions (FAQ)
What is a Unix timestamp?
A Unix timestamp (also called a POSIX timestamp or epoch time) is an integer representing the number of seconds elapsed since the Unix epoch: 1970-01-01 00:00:00 UTC. The choice of that date is a historical convention from the early Unix operating system.
Because the timestamp is a single integer independent of time zones and calendar systems, it is the standard way most computer systems store and transmit instants of time. Converting it to a human-readable date requires knowing which time zone to apply; this calculator always uses Coordinated Universal Time (UTC).
Seconds or milliseconds? How do I tell which one my value is?
Standard Unix timestamps count whole seconds. A 10-digit value (for example 1,700,000,000) is almost certainly seconds — that corresponds to a date in 2023. A 13-digit value (for example 1,700,000,000,000) is almost certainly milliseconds, as produced by JavaScript's Date.now() and Date.getTime(), or by many REST APIs and log systems.
As a rule of thumb: if the number has ten digits it is seconds; if it has thirteen it is milliseconds. Values with eleven or twelve digits fall in a gap and may be microseconds or a non-standard scale — verify with the source documentation.
What is the Year 2038 problem?
Many older systems store Unix timestamps as a 32-bit signed integer, which can hold values from −2,147,483,648 to 2,147,483,647. The maximum positive value corresponds to 2038-01-19 03:14:07 UTC. After that moment the counter overflows back to a large negative number, which those systems would interpret as a date in 1901.
Modern systems use 64-bit integers, which can represent dates hundreds of billions of years in the future. The problem is confined to legacy embedded systems, older databases, and software that has not been updated. Most mainstream operating systems and programming languages have already moved to 64-bit time.