ReckonBoxHow the Unix timestamp converter works
A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, and this converter turns one into a readable date, or a date back into one. Paste the number straight out of a log line or a database column. The unit comes from the digit count, the date is rendered against the time zone you pick, and the result carries the checks that matter: which unit was assumed, what the same digits would mean under the other reading, and whether the value crosses the boundary that breaks 32-bit systems.
The number has no zone attached, which is the whole point of storing it. It names one instant, identically, on every machine that reads it.
Seconds, milliseconds, and the mistake that ships
Count the digits. Ten is seconds, thirteen is milliseconds, sixteen microseconds, nineteen nanoseconds. The split follows the language you are working in.
| Unit | Digits | Comes from |
|---|---|---|
| Seconds | 10 | date +%s, PHP time(), Python time.time(), Ruby, most SQL databases |
| Milliseconds | 13 | JavaScript Date.now(), Java System.currentTimeMillis(), Node |
| Microseconds | 16 | Postgres internals, some tracing systems |
| Nanoseconds | 19 | Go time.UnixNano(), high-resolution profilers |
Get it wrong in one direction and you cannot miss it: hand a thirteen-digit millisecond value to a seconds parser and PHP returns a date in the year 56970. Get it wrong in the other and you might never notice, because ten digits of seconds handed to the JavaScript Date constructor lands on 21 January 1970. That is a plausible-looking date. It ships.
Half the tools on this search make you choose the unit by hand. This one detects it and then prints what the value would have meant read the other way, so the failure is visible before it becomes a bug report.
Unix time does not count leap seconds
This is where nearly every converter goes quiet, and where the one page that speaks up has it backwards.
Unix time counts non-leap seconds. Every day contains exactly 86,400 of them, by definition, whether or not a leap second was inserted that day. When a positive leap second happens, the Unix number runs on into the next day and then jumps back by one, so the same value is repeated for a second. It does not gain an extra tick.
The consequence is worth stating plainly: more SI seconds have physically elapsed since 1970 than the timestamp reports. If you are reconciling timestamps against an atomic clock, a GPS feed or a scientific instrument, that gap is real and Unix time will not show it to you.
Of ten converter pages checked for this build, nine say nothing about leap seconds at all, and one states that a leap second is handled "by adding an extra second at midnight", which is the opposite of what the specification does.
The year 2038 problem
A signed 32-bit integer stops at 2147483647, and that value is 19 January 2038 at 03:14:07 UTC. One second later the field overflows: it wraps to a large negative number and the date reads as 1901, or the system throws.
The fix is not clever encoding, it is a wider column. A signed 64-bit integer spans roughly 292 billion years either side of the epoch, which comfortably outlasts the problem. Most modern systems have already moved, but embedded firmware, old file formats and 32-bit database columns have not, and expiry dates thirty years out are already crossing the line today. This tool flags any value past the ceiling in either direction of conversion.
Dates before 1970, and why the zone still matters
Negative timestamps count backwards from the epoch, so -86400 is 31 December 1969. They are valid, and they are also where implementations diverge: some languages and drivers reject them outright, others reinterpret them as very large positive numbers. Worth testing before you store a birth date that way.
As for zones: the timestamp is absolute, but the date you read off it is not. Converting needs a zone, and the offset for that zone depends on the instant, because daylight saving rules change over the decades. The United States moved its clock-change dates in 2007. Render a 1985 New York timestamp against today's rules and the wall clock is an hour off. epochconverter warns in its own instructions that some browsers do exactly this, and one competing tool lists the absence of historical zone conversion among its own limitations.
This converter reads the offset from the time zone database for the exact instant, and offers the full IANA list rather than a UTC and local toggle. It is the same machinery behind the time zone converter.
What this converter leaves out
Other epochs are named here but not converted. GPS time, Windows FILETIME, Mac HFS+ and LDAP timestamps each count from a different origin, and GPS time does count leap seconds, so converting them needs their own offsets rather than a guess.
Leap-second-accurate arithmetic is out too. Explaining what Unix time does with leap seconds is one thing; converting to atomic time needs a leap-second table that changes by IERS bulletin, and a stale table is worse than none.
Batch conversion is deliberately absent, since one clear conversion is the job here. For the gap between two moments the duration calculator handles it, and for date arithmetic in plain calendar terms the date calculator is the better fit.
Frequently asked questions
What is a Unix timestamp? It is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. Because it is a single number with no zone attached, it names the same instant everywhere, which is why logs, APIs and databases store it instead of a formatted date.
How do I tell seconds from milliseconds? Count the digits. Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds and nineteen is nanoseconds. The split follows the language: date +%s, PHP time(), Python time.time() and most SQL databases give seconds, while JavaScript Date.now(), Java System.currentTimeMillis() and Node give milliseconds. This tool detects the unit and also prints what the same digits would have meant under the other reading.
What happens if I read the wrong unit? The result is wrong in a way that is easy to miss in one direction and impossible to miss in the other. Hand thirteen digits to a seconds parser and PHP returns a date in the year 56970. Hand ten digits of seconds to the JavaScript Date constructor and you land on 21 January 1970, which looks plausible enough to ship.
Does Unix time count leap seconds? No, and this is the part most converters skip. Unix time counts non-leap seconds, holding every day at exactly 86,400 seconds. During a positive leap second the number runs on into the next day and then jumps back by one, so the same Unix time value is repeated for that second. The practical consequence: more SI seconds have physically elapsed since 1970 than the timestamp reports, which matters if you are reconciling against an atomic clock or a GPS feed.
What is the year 2038 problem? A signed 32-bit integer tops out at 2147483647, which is 19 January 2038 at 03:14:07 UTC. A system still storing seconds in 32 bits overflows one second later and wraps to 1901 or fails outright. A signed 64-bit field covers roughly 292 billion years in either direction, so the fix is a wider column, not a clever encoding. This tool flags any value past that ceiling.
Can a timestamp be negative? Yes. A negative value counts backwards from the epoch, so -86400 is 31 December 1969. Not every system accepts them: some languages and database drivers reject negative timestamps or reinterpret them as very large positive numbers, so check before you store a pre-1970 date this way.
Why does the time zone matter if the timestamp is absolute? The timestamp is absolute, but the date you read off it is not. Converting requires a zone, and the offset for that zone depends on the instant, because daylight saving rules change over time. A 1985 New York timestamp needs the 1985 rules, not this year, and epochconverter warns that some browsers apply current rules to all past dates. This tool reads the offset from the time zone database for the exact instant.
Does this handle other epochs, like GPS or Windows FILETIME? No. GPS time, Windows FILETIME, Mac HFS+ and LDAP timestamps each count from a different origin and, in the GPS case, do count leap seconds. Converting them needs their own offsets, so this tool stays with Unix time rather than guessing.