Unix Timestamp Conversion: Seconds, Milliseconds and 2038

#The digit count tells you the unit

A Unix timestamp is an offset from 1970-01-01 00:00:00 UTC, and its length tells you the unit. Keep this table handy; it resolves most "the date is wrong" reports on sight.

The rule is simple: count the digits, then decide whether to divide by 1000. Adjacent magnitudes always differ by exactly 1000, which is why a unit mistake throws the date off by a factor of a thousand.

#Why timezones are irrelevant to a timestamp

A timestamp identifies an absolute instant, and that instant does not change based on where the observer stands. Noon in Beijing on 2026-10-14 and 04:00 UTC on the same day are the same moment, so they share one timestamp.

A timezone only enters the picture at the last step, when that instant is rendered as a readable date string:

So the correct pattern is: store UTC timestamps everywhere in the database and API, and convert to the viewer's timezone only for display. Store local time as a string and cross-timezone debugging plus DST transitions will keep producing bugs.

#Three conversion scenarios

#Scenario 1: date to timestamp

Defaults differ per language and database, which is where cross-team bugs originate:

When values cross a language boundary, put the unit in the field name. created_at_ms prevents every future reader from having to guess.

If you also need a unique identifier per record, consider a time-ordered scheme - the v7 variant from UUID / GUID Generator increases with time, satisfying uniqueness and sortability at once.

#Scenario 2: timestamp to date

Paste the value into the Unix Timestamp tool - it infers the unit from the digit count and lets you override. On the command line:

# seconds to local time
date -d @1791950400

# milliseconds to seconds to local time
date -d @$((1791950400000/1000))

#Scenario 3: measuring an interval

Subtract values in the same unit. Durations are stated in seconds or milliseconds, and mixing them produces a result that is off by 1000x:

{ "created_at_ms": 1791950400000, "ttl_sec": 3600 }

Field names like these eliminate most misuse, because the unit travels with the value.

To confirm two datasets migrated consistently, put both timestamp columns side by side with Text Diff. And when inspecting a timestamp field in an API response, run it through JSON Formatter first so the field names are visible at a glance.

#The Year 2038 problem: when it still matters

The largest value a signed 32-bit integer holds is 2147483647, which corresponds to 2038-01-19 03:14:07 UTC. Past that instant, programs storing seconds in 32 bits overflow into negative numbers and report dates around 1901.

Do you still need to care? It depends on the environment:

#Frequently asked questions

#What date is timestamp 0?

Timestamp 0 is 1970-01-01 00:00:00 UTC, which is 1970-01-01 08:00 in Beijing. It frequently serves as an "unset" default, so a table full of 1970 dates usually means the column was never written rather than that the event happened then. Negative values are legal and represent instants before 1970.

#Why is the time in my frontend off by 8 hours from the backend?

Two likely causes. Either the backend returned a local-time string and the frontend parsed it as UTC, or the backend treated local time as a timestamp. Diagnosis: divide the returned value by 3600 - if the difference is exactly the local UTC offset, the bug is in timezone handling, not in the timestamp format.

#Can I truncate a millisecond timestamp to seconds?

Yes, but understand the cost: truncation reduces precision to whole seconds, so records created within the same second can no longer be ordered. That is fine for counting how many events happened on a given day. Keep milliseconds if you sort by the value.

#Do timestamps account for leap seconds?

No. Unix time flattens leap seconds by defining a day as exactly 86400 seconds, so the system clock repeats or skips an instant when a leap second occurs. The resulting drift against UTC is negligible for almost all software; only astronomy and satellite systems handle it explicitly.

#How can I sanity-check a conversion?

Use two known anchors: 0 must render as 1970-01-01 00:00 UTC, and 1000000000 must render as 2001-09-09 01:46:40 UTC. If both are correct, the tool and timezone settings are fine and you can inspect the specific value. To reason about recurring intervals instead, use Cron Generator.