Hidden inside every API response, log file, and database is the strangest timestamp convention in computing: a single large number counting the seconds since midnight on January 1, 1970. It is called Unix epoch time, it currently reads around 1.78 billion, and once you know its three quirks, the ten-digit rule, the milliseconds trap, and the year 2038, you can read any timestamp a system throws at you. Our free epoch converter translates in both directions instantly.
In this guide
Why 1970, and why a single number
Unix needed a birthdate for its clock, and its developers in the early 1970s picked a recent, round starting line: 00:00:00 UTC, January 1, 1970, now called the epoch. Everything after is a count of elapsed seconds; everything before is negative. The single-number design is the entire point: comparing two moments is integer comparison, durations are subtraction, and no parsing of months, time zones, or formats is involved until a human needs to read the result. That is why systems store epochs and convert at the edges, and why the number, not the pretty date string, is what your logs and APIs actually exchange. The number is also always UTC by definition, which quietly solves the time zone problem for storage: one moment, one number, worldwide.
Reading an epoch at a glance
A few anchors make raw epochs readable without a converter:
| Epoch | Moment (UTC) | Worth remembering as |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | the epoch itself |
| 1,000,000,000 | 2001-09-09 01:46:40 | the billion rollover |
| 1,780,000,000 | mid-2026 | roughly now |
| 2,000,000,000 | 2033-05-18 03:33:20 | the two-billion mark |
| 2,147,483,647 | 2038-01-19 03:14:07 | the 32-bit ceiling |
The working rule: a 10-digit number starting with 17 or 18 is a current-era timestamp in seconds. Each year adds about 31.6 million, so two epochs differing in the eighth digit are days apart, in the sixth, minutes. For exact values, the converter does both directions, and the companion seconds to time tool turns raw durations (say, 93,784 seconds) into human form (1 day, 2:03:04).
The milliseconds trap
The most common epoch bug in practice is a factor of one thousand. Unix tradition counts seconds (10 digits today); JavaScript and many APIs count milliseconds (13 digits today). Paste a millisecond value into a seconds field and the date lands tens of thousands of years in the future; divide when you should not and everything happens in 1970. The diagnosis is just digit-counting: 10 digits, seconds; 13 digits, milliseconds; 16, microseconds; 19, nanoseconds. Every “why is my date in the year 58,000” question ever asked is this paragraph.
The year 2038 problem
Old systems store the epoch in a signed 32-bit integer, whose maximum value is 2,147,483,647. That second arrives at 03:14:07 UTC on January 19, 2038, after which a 32-bit counter wraps to negative and a confused system thinks it is December 1901. It is the Y2K of the Unix world, with one difference: the fix, 64-bit time, is already standard on modern systems and extends the count beyond the lifetime of the sun. The remaining risk lives in embedded devices, old file formats, and forgotten 32-bit code, which is why the date still earns a section in every epoch guide and a calendar entry in every infrastructure team’s far future.
Working with epochs in practice
- Reading a log or API value: count digits, convert, and remember the result of a bare epoch is UTC; your wall clock may be hours away.
- Comparing two timestamps: subtract the raw numbers first, then humanize the difference; converting both to date strings and eyeballing is where mistakes creep in.
- Storing times in anything you build: store epochs (or UTC timestamps), convert for display only. Every system that stored local wall-clock times has a daylight-saving war story.
- Why the number system matters: the epoch is also a nice everyday example of plain base-10 counting doing heavy lifting, a thread that continues in our number systems guide, and the wider toolbox lives in the date and time hub.
Frequently asked questions
Does epoch time include leap seconds?
No, and this is deliberate: Unix time pretends every day has exactly 86,400 seconds, absorbing leap seconds by convention. It keeps the arithmetic clean at the cost of being technically a few dozen seconds adrift of atomic time, a trade nearly every system accepts.
Why did I get a date in 1970 when converting?
Your value was probably zero, empty, or already divided by 1,000 one time too many. A near-1970 date almost always means a missing or mangled timestamp rather than a real one.
Can epochs be negative?
Yes: negative values count seconds before 1970, so historical dates are representable. Not every system accepts them, but the convention itself extends both directions.
Is there a maximum epoch with 64-bit time?
Technically yes, comfortably beyond 290 billion years. The 2038 ceiling was an implementation detail of 32-bit storage, not of the idea; with 64 bits, the idea outlives the universe’s interesting parts.