Why is my Unix timestamp showing 1970
Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. A Unix timestamp shows 1970 when a near-zero or wrongly scaled value is read against the epoch. Paste the number into the Tools Nimbus Unix Timestamp Converter: it reads both seconds and milliseconds, shows which unit fits, and returns the real UTC and local date.
Last updated June 2026
What 1970 actually means
A Unix timestamp counts the seconds (or milliseconds) elapsed since the Unix epoch: midnight UTC on January 1, 1970. The epoch itself is the value 0. So any time your code prints a 1970 date, it is telling you the number it converted was either exactly zero or a small value sitting just after the epoch. The converter is not broken. The value it received was wrong, or it was measured in a different unit than the function expected.
There are only a handful of ways to land in 1970, and each leaves a distinct fingerprint. Match your symptom to the table below, then read the matching section.
Symptom, cause, and fix at a glance
| Symptom | Most likely cause | Fix |
|---|---|---|
| Date lands in Jan 1970 from a 10-digit number | Seconds passed to a millisecond function (JavaScript new Date()) | Multiply by 1000: new Date(ts * 1000) |
| Exactly 1970-01-01 00:00:00 UTC | Value is 0, null, or missing (null coerces to 0) | Trace the value to its source; it was never set |
| Date is decades in the future, not 1970 | Milliseconds read as seconds | Divide by 1000: new Date(ts / 1000) only if the target wants seconds |
Invalid Date instead of 1970 | Empty string, undefined, NaN, or non-numeric text | Parse to a number and confirm it is not empty first |
| Right day, wrong hours | Time zone: UTC shown as local, or local read as UTC | Compare the UTC and local values explicitly |
Cause 1: seconds read as milliseconds (the usual one)
This is the single most common reason and it is specific to languages that measure time in milliseconds. JavaScript's Date constructor expects milliseconds. A normal current timestamp in seconds, for example 1750000000, is ten digits. Hand that straight to new Date(1750000000) and JavaScript reads it as 1,750,000,000 milliseconds, which is about 20.3 days after the epoch: January 21, 1970. The value was correct; the unit was not.
The fix is to scale to milliseconds before constructing the date:
// seconds from an API, a database, or a JWT
const ts = 1750000000;
new Date(ts); // Wed Jan 21 1970 <- wrong unit
new Date(ts * 1000); // Fri Jun 15 2025 <- correctThe tell-tale sign is a 1970 date produced from a ten-digit number. If you are unsure which unit you hold, paste the raw number into the Unix Timestamp Converter. It interprets the value as seconds and as milliseconds and shows both resulting dates, so the unit that yields a believable year is the one you want.
Cause 2: the value is zero, null, or missing
If the date is not just in 1970 but exactly 1970-01-01 00:00:00 UTC, the number you converted was 0. The trap in JavaScript is that null coerces to 0, so new Date(null) returns the epoch rather than failing. A database column that came back NULL, a JSON field that was absent, or a variable that was never assigned can all flow through as null and print the epoch. Treat this date as a sign the value was never set, and fix the source query or default instead of the formatting code.
Note the difference from undefined: new Date(undefined) returns Invalid Date, not 1970. So an exact-epoch result points at a real zero or a null, which narrows the hunt considerably.
Cause 3: the far-future mirror image
The same confusion runs the other way. If you pass a 13-digit millisecond value to a function that expects seconds, such as PHP's date() or Python's datetime.fromtimestamp(), you do not get 1970. You get a date tens of thousands of years in the future, because the number is a thousand times too large for the unit. It is the same root cause, seconds versus milliseconds, so the same digit-counting check applies: ten digits is seconds, thirteen digits is milliseconds for any moment in the current era.
Cause 4: it is a string, not a number
Sometimes the value arrives as text. "1750000000" is a string, and depending on how you use it you may get coercion surprises. Worse, a string with stray characters, a trailing newline, or thousands separators parses to NaN and yields Invalid Date rather than 1970. If you see Invalid Date, the input never became a number. Run it through Number(value) (or parseInt for integer strings) and verify the result is finite before doing any date math.
How to diagnose it in one step
You can settle the unit question without writing any code. Open the Unix Timestamp Converter and paste the exact number you are debugging. It runs entirely in your browser, so a timestamp pulled from production logs or a customer record never leaves your machine. The converter shows the date for both the seconds and the milliseconds reading, plus the UTC and local versions, so you can immediately see which unit gives a plausible year and whether a time-zone offset, not the unit, is the real issue. If the value came out of a JSON payload or a token, you can sanity-check the surrounding data with the JSON Formatter or pull the exp and iat claims from a token with the JWT Decoder, both of which store seconds.
How to prevent it
- Pick one unit per system and document it. Most backends and databases use seconds; JavaScript and many browser APIs use milliseconds.
- Convert at the boundary. When seconds enter JavaScript, multiply by 1000 once, right where the data arrives, not scattered through the UI.
- Count digits as a quick check: ten digits is seconds, thirteen is milliseconds for any date near today.
- Guard against zero and null before formatting, so a missing value shows an empty state rather than a misleading 1970 date.
- When a date looks wrong, paste the raw number into the Unix Timestamp Converter before changing code, and browse the Tools Nimbus guides for related developer fixes.