> timestamp | epoch | convert <
// Convert Unix timestamps to dates and dates to timestamps instantly
Real-time Clock
Live updating Unix timestamp display. See the current epoch time ticking in real-time.
Two-way Conversion
Convert timestamps to human-readable dates and dates back to timestamps. Both directions supported.
Multiple Formats
View results in ISO 8601, RFC 2822, UTC, local time, and relative time formats.
// ABOUT UNIX TIMESTAMPS
How Unix Timestamps Work:
A Unix timestamp (also known as epoch time or POSIX time) represents the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC (the Unix epoch). This simple integer value provides a universal, timezone-independent way to represent a specific moment in time.
Example:
1711324800 → 2024-03-25T00:00:00.000Z
Common Use Cases:
- >Database timestamp storage and querying
- >API response time fields
- >Log file timestamp analysis
- >Debugging time-related issues
- >Cross-timezone time coordination
- >The Y2K38 problem: 32-bit signed integers overflow on January 19, 2038
>> frequently asked questions
Q: What is a Unix timestamp?
A: A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC. It is a simple integer value used universally in computing to represent a specific point in time, independent of timezones.
Q: What is epoch time?
A: Epoch time is another name for Unix timestamp. The "epoch" refers to the reference point: January 1, 1970 00:00:00 UTC. All Unix timestamps are measured as the number of seconds since this epoch.
Q: What is the Unix epoch?
A: The Unix epoch is the reference starting point for Unix timestamps — January 1, 1970 00:00:00 UTC (also written as 1970-01-01T00:00:00Z). This date was chosen as a simple, timezone-neutral origin when Unix was being developed, and it has since become the de facto standard for computing time across virtually every operating system and programming language.
Q: How do I convert epoch time to a human-readable date?
A: Paste the epoch value into the TIMESTAMP INPUT field above and click [TO DATE]. Our converter will output the date in ISO 8601, RFC 2822, UTC, local time, and a relative format. Programmatically, you can use new Date(epoch * 1000) in JavaScript, datetime.fromtimestamp(epoch) in Python, or date -r <epoch> on Linux/macOS.
Q: How do I convert a date to an epoch timestamp?
A: Use the DATE INPUT field above and click [TO TIMESTAMP]. Programmatically: JavaScript — Math.floor(Date.now() / 1000); Python — int(datetime.now().timestamp()); PHP — time(); Linux shell — date +%s; Go — time.Now().Unix().
Q: What is the current Unix epoch time?
A: The live counter at the top of this page shows the current Unix timestamp, updating every second. It represents the exact number of seconds that have elapsed since January 1, 1970 UTC up to this moment.
Q: What is the Y2038 problem?
A: The Year 2038 problem (Y2K38) occurs because many systems store Unix timestamps as 32-bit signed integers, which can only represent times up to January 19, 2038 03:14:07 UTC. After that, the value overflows. Modern systems use 64-bit integers to avoid this.
Q: What is the difference between seconds and milliseconds timestamps?
A: Unix timestamps in seconds are 10 digits long (e.g., 1711324800), while millisecond timestamps are 13 digits (e.g., 1711324800000). JavaScript's Date.now() returns milliseconds, while most Unix/Linux tools use seconds. Some APIs also use microseconds (16 digits) or nanoseconds (19 digits).
Q: Can Unix timestamps be negative?
A: Yes, negative Unix timestamps represent dates before January 1, 1970. For example, -86400 represents December 31, 1969. This is useful for representing historical dates in computing systems.
Q: Is Unix timestamp in UTC or local time?
A: Unix timestamps are always in UTC — they do not carry any timezone information. The integer itself is an absolute instant in time. When you display it as a human-readable date, that is when a timezone is applied. This is why epoch time is so widely used: two machines anywhere in the world can exchange timestamps without ambiguity.
Q: How are leap seconds handled in Unix epoch time?
A: Unix time does not count leap seconds — it treats every day as exactly 86,400 seconds. When a leap second is inserted (e.g., 23:59:60 UTC), Unix time either repeats or smears the second depending on the system. This keeps arithmetic simple but means Unix time is not exactly the same as UTC during leap second events.
Q: What is a useful reference table of epoch values?
A: Some well-known reference points: 0 = 1970-01-01 00:00:00 UTC (Unix epoch) 86400 = 1970-01-02 00:00:00 UTC (one day after epoch) 946684800 = 2000-01-01 00:00:00 UTC (Y2K) 1000000000 = 2001-09-09 01:46:40 UTC (the billion-second milestone) 1234567890 = 2009-02-13 23:31:30 UTC 1577836800 = 2020-01-01 00:00:00 UTC 1704067200 = 2024-01-01 00:00:00 UTC 2147483647 = 2038-01-19 03:14:07 UTC (32-bit signed int max — Y2038)
Q: Why does my epoch converter give a different date than expected?
A: The most common causes are: (1) confusing seconds and milliseconds — a 13-digit value is milliseconds, not seconds; (2) timezone display — the same epoch shows different wall-clock times in UTC vs local time; (3) the epoch is 1970-01-01 UTC, not local time; (4) some systems use a different epoch (e.g., NTP uses 1900-01-01, Windows FILETIME uses 1601-01-01) — those values are not Unix timestamps and need conversion first.