Unix Timestamp in Milliseconds vs Seconds

The problem in one paragraph

Unix time is defined in seconds, but a great deal of software counts in milliseconds instead, because a second is a coarse unit for measuring anything a computer does. Neither number carries a label. When a millisecond value crosses into code expecting seconds, or vice versa, nothing throws an error — you just get a date that is wrong by a factor of a thousand. That is roughly 53 years in one direction and 54,000 years in the other, which at least makes the mistake easy to spot once you know the symptom.

Who counts in what

The single most common collision is a JavaScript front end talking to a Python or PHP back end. The front end sends 13 digits, the back end calls datetime.fromtimestamp() on it, and either raises an out-of-range error or stores a date tens of thousands of years in the future.

How this tool decides

The rule is a magnitude threshold, applied to the absolute value so it works for negative timestamps too:

|value| >= 100000000000  (10^11)   →  milliseconds
|value| <  100000000000            →  seconds

Which puts the boundary here:

The trade-off is deliberate. Below the threshold, treating a value as seconds is safe up to the year 5138 — no genuine seconds timestamp will ever be that large in any system you or your grandchildren will use. Above it, the only values misread are millisecond timestamps from between 1970 and 3 March 1973, which are vanishingly rare in practice. If you happen to be working with exactly that range, or with any value where the guess is wrong, the Seconds and Milliseconds radio buttons force the interpretation and the label under the input tells you the override is active.

Converting between units in code

Multiplying and dividing by 1,000 is trivial; the things worth getting right are rounding and integer width.

// JavaScript
const seconds = Math.floor(Date.now() / 1000);   // ms -> s, floor not round
const millis  = seconds * 1000;                  // s -> ms

# Python
import time
seconds = int(time.time())                       # already seconds
millis  = int(time.time() * 1000)

// Java
long millis  = System.currentTimeMillis();
long seconds = millis / 1000L;                   // integer division floors

// Go
now     := time.Now()
seconds := now.Unix()
millis  := now.UnixMilli()

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM now())::bigint;        -- seconds
SELECT (EXTRACT(EPOCH FROM now()) * 1000)::bigint;

Two traps. First, use floor rather than round when going from milliseconds to seconds: rounding can push a timestamp into the next second and break exact-match comparisons. Note that floor and integer division diverge for negative values in some languages — Python’s // floors, C and Java integer division truncates toward zero, so -1500 / 1000 is -2 in Python and -1 in Java. For pre-1970 timestamps that one-second difference is a real bug.

Second, a millisecond timestamp needs 64 bits. It exceeded the signed 32-bit maximum back in 1970 plus 25 days, so never store one in an INT column — use BIGINT.

Questions

Related tools

• Timestamp to dateTurn an epoch number into a readable date in any time zone.
• Date to timestampGo the other way: calendar date and clock time to an epoch integer.
• Seconds vs millisecondsWhy your date landed in 1970 or in the year 55840, and how to fix it.

More tools on this site

• Cron expression generatorBuild the schedule that produces the run times you're converting
• Days untilCount the days between two dates instead of converting a single instant