The number that means nothing at a glance

1735689600 is a perfectly valid date. So is 1735689600000. They are a second apart in meaning and a thousand times apart in magnitude, and telling them apart by eye is the first thing that trips people up.

Both are Unix timestamps: the count of time since 1970-01-01T00:00:00Z, known as the epoch. Databases store them, APIs return them, logs are full of them — and humans cannot read them.

Seconds or milliseconds?

The rule is simple once you know it:

Digits Unit Typical range
10 seconds 2001 → 2286
13 milliseconds same dates, ×1000

JavaScript’s Date.now() returns milliseconds. Most backend languages and Unix commands return seconds. That mismatch is a genuine classic: a millisecond value divided by 1000 gives a date in 1970, and a second value treated as milliseconds lands somewhere in 1970 too.

The Unix timestamp converter detects the difference automatically and shows both.

Why your conversion looks wrong: time zones

A timestamp has no time zone — it is an absolute instant. Your rendering of it does.

  • 2026-01-01T00:00:00Z (UTC) is 2026-01-01 08:00:00 in Beijing
  • It is 2025-12-31 19:00:00 in New York

So when a timestamp “shows the wrong day”, the bug is almost always a missing Z, a missing time zone offset, or a server that formats in local time while the client expects UTC.

The converter shows an ISO 8601 (UTC) row and a local time row side by side, which makes the difference obvious.

Reading timestamps in practice

In a database: store UTC, render in the user’s time zone. Storing local time is one of the few date decisions that is genuinely hard to undo.

In logs: a 10-digit number next to a request is almost always seconds since epoch.

In an API: check the field name — created_at, createdAt and timestamp all tend to be epoch values, but you cannot assume the unit. Look at the digit count.

In JavaScript:

// seconds → Date
new Date(1735689600 * 1000)

// milliseconds → Date
new Date(1735689600000)

// Date → seconds
Math.floor(Date.now() / 1000)

Common pitfalls

  1. Mixing units. Multiply or divide by 1000 exactly once — the bug is usually a double conversion.
  2. Assuming local time. new Date('2026-01-01') is parsed as UTC, while new Date('2026-01-01 00:00:00') (with a space) is treated as local in most engines.
  3. Leap seconds. Unix time ignores them; do not try to be clever.
  4. Year 2038. 32-bit signed timestamps overflow on 2038-01-19. Use 64-bit or milliseconds.
  5. Negative values. They are valid and mean dates before 1970.

Converting by hand vs with a tool

For a one-off check, the browser console is fine. For anything repetitive — debugging an API, lining up log entries with user reports, writing tests — a converter that shows seconds, milliseconds, UTC, local time, weekday and a relative description in one view saves a surprising amount of time. Try the converter; it runs locally and works offline.

FAQ

Does a Unix timestamp include a time zone? No. It is a single instant; time zones only appear when you format it.

Why is my timestamp in 1970? Almost always a unit mismatch — you divided seconds by 1000, or passed seconds where milliseconds were expected.

What about ISO 8601 strings? They are the human-readable alternative (2026-01-01T00:00:00Z). Prefer them in APIs you design, and accept both when consuming.

Can a timestamp be negative? Yes, for dates before 1970.