You are reading a log file and see a timestamp: 1711382400. What time is that? You encounter a JWT token with an exp field of 1743004800. When does it expire? You are debugging an API response with a created_at field of 1679616000. When was it created?
Epoch time (Unix time) is everywhere in computing, and being able to read it or convert it quickly is a genuine productivity skill.
What epoch time is
Epoch time is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC. This moment is called the Unix epoch, chosen arbitrarily when the Unix operating system was being developed.
The current epoch time is approximately 1,774,000,000 (as of early 2026). It increments by 1 every second. It does not account for leap seconds (UTC inserts them, but Unix time pretends they do not exist, which creates the occasional 1-second discrepancy).
Why it exists
Human-readable dates are terrible for computation. "March 25, 2026 3:00 PM EDT" contains timezone information, locale-specific formatting, ambiguous abbreviations, and varying month lengths. Comparing two such dates requires parsing, timezone conversion, and calendar arithmetic.
Epoch time is a single integer. Comparing two times is a subtraction. "How many seconds between two events" is event2 - event1. "Was this timestamp before or after another" is a < b. No parsing, no timezone confusion, no date arithmetic.
Common epoch time operations
Current time: In most languages, getting the current epoch time is one function call:
Math.floor(Date.now() / 1000) // JavaScript (Date.now() returns milliseconds)
import time; int(time.time()) # Python
date +%s # Unix/Linux shell
Convert to human-readable:
new Date(1711382400 * 1000).toISOString()
// "2024-03-25T16:00:00.000Z"
Convert from human-readable:
Math.floor(new Date('2024-03-25T16:00:00Z').getTime() / 1000)
// 1711382400
Seconds vs milliseconds
This is the most common source of errors. Unix epoch time is in seconds. JavaScript's Date.now() and Date.getTime() return milliseconds. Java's System.currentTimeMillis() returns milliseconds. Python's time.time() returns seconds with decimal fractions.
If an epoch timestamp has 10 digits, it is seconds (valid range approximately 1,000,000,000 to 2,000,000,000, covering roughly 2001 to 2033).
If it has 13 digits, it is milliseconds. Divide by 1,000 to get seconds.
If it has 16 digits, it is microseconds (used by some databases). Divide by 1,000,000.
If it has 19 digits, it is nanoseconds (used by Go's time.UnixNano()). Divide by 1,000,000,000.
The 2038 problem
Unix epoch time stored as a signed 32-bit integer overflows on January 19, 2038 at 03:14:07 UTC. The maximum value of a signed 32-bit integer is 2,147,483,647 seconds after epoch.
This is the Y2K of Unix systems. Most modern systems use 64-bit integers, which extends the range to approximately 292 billion years. But embedded systems, legacy databases, and some file formats still use 32-bit timestamps. If your system will be running in 2038 (it is only 12 years away), audit your timestamp storage now.
Quick reference points
Memorable epoch timestamps worth knowing:
- 0: January 1, 1970 00:00:00 UTC
- 1,000,000,000: September 9, 2001 01:46:40 UTC
- 1,234,567,890: February 13, 2009 23:31:30 UTC
- 1,700,000,000: November 14, 2023 22:13:20 UTC
- 2,000,000,000: May 18, 2033 03:33:20 UTC
- 2,147,483,647: January 19, 2038 03:14:07 UTC (32-bit overflow)
The converter
For quick conversion between epoch time and human-readable dates in any timezone, I built an epoch time converter that handles seconds, milliseconds, and microseconds and shows the result in multiple timezone formats simultaneously.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)