Convert a Unix timestamp to a date (and back) without the 1970 bug

A Unix timestamp is a count of seconds since January 1, 1970 UTC, and sooner or later you meet one in a log line, an API response, or a database column and need to know what moment it actually names. The fastest route is the Timestamp Converter: paste the value, read the date, or type a date and get the timestamp back, all in your browser with a live current timestamp and timezone support. If you want the background, where the count comes from, why 2038 matters, the theory lives in Unix timestamps and epoch time explained. This post is just the practical task.

Timestamp to date

Paste the number into the converter and it shows the readable date in UTC and in your local timezone. The one thing to check before you trust the result is the unit.

• A 10 digit value like 1784016000 is seconds. This is the classic Unix timestamp, what most APIs and databases store.
• A 13 digit value like 1784016000000 is milliseconds. JavaScript's Date.now() and many logging systems produce these.

The converter detects this from the digit count, but if you convert by hand and get it wrong, the failure mode is unmistakable. Treat a seconds value as milliseconds and you divide the real moment by a thousand, landing in January 1970, a few weeks after the epoch. Treat a milliseconds value as seconds and you multiply it by a thousand, landing somewhere past the year 50,000. If your date looks like either of those, you have a unit problem, not a data problem.

Date to timestamp

The reverse direction works the same way: enter a date and time in the converter and it returns the Unix timestamp. The detail that matters is the timezone of the date you typed. A wall clock time like 2026-07-14 08:00 is ambiguous until you say where the clock is; 08:00 in Tokyo and 08:00 in New York are thirteen hours apart, so they produce different timestamps. Pick the timezone the original time was recorded in, not the one you happen to be sitting in.

Timezones: one instant, many faces

A Unix timestamp is an absolute instant. It has no timezone of its own; it is anchored to UTC by definition. The human readable date you see is a rendering of that instant in some display timezone, which is why the same timestamp looks different to colleagues in different offices while meaning exactly the same moment.

Here is the timestamp 1784016000 rendered three ways:

Three different clock readings, one instant. This is also the usual cause of the "timestamps are off by a few hours" bug report: the values are correct, but one system is rendering them in server time and another in the viewer's local time. Compare the raw timestamps, not the formatted strings.

Quick reference

For the cases where you are already in code rather than a browser tab:

JavaScript
  timestamp -> date:  new Date(1784016000 * 1000)          // seconds need * 1000
  date -> timestamp:  Math.floor(Date.now() / 1000)        // now, in seconds

Python
  timestamp -> date:  datetime.fromtimestamp(1784016000, tz=timezone.utc)
  date -> timestamp:  int(dt.timestamp())

SQL (Postgres)
  timestamp -> date:  SELECT to_timestamp(1784016000);
  date -> timestamp:  SELECT extract(epoch FROM now())::bigint;

Note the JavaScript asymmetry: Date works in milliseconds while Unix timestamps are conventionally seconds, so you multiply going in and divide coming out. That single detail causes most of the 1970 bugs described above.

For anything beyond a quick conversion, the Timestamp Converter handles both directions, both units, and the timezone rendering for you. For why the count works the way it does, see Unix timestamps and epoch time explained.