Unix timestamp converter: 10-digit seconds, 13-digit milliseconds

When you actually need it

A log line contains nothing but a number and you need to know what local time and UTC it represents. When debugging across time zones, seeing both side by side beats doing arithmetic in your head.

Before writing a timestamp to a database or API, you need to turn 2026-10-25 15:30:00 into Unix seconds and confirm there is no offset. Some APIs want seconds, others want milliseconds, and a factor-of-1000 mistake is far from subtle.

You are checking a third-party expires_at or iat field: first work out whether it is seconds or milliseconds, then judge whether the decoded time makes sense.

• Turn a bare number in a log into local time and UTC
• Convert a local datetime to seconds before writing to a database
• Check whether an API field is seconds or milliseconds
• Compare local time with UTC

How to get it right

Count the digits: 10 digits is seconds, 13 is milliseconds, and they differ by 1000. This tool compares the absolute value against 10^11 — below is seconds, at or above is milliseconds — so 12- and 13-digit values are milliseconds while 11 digits still counts as seconds. Input with a decimal point is treated as milliseconds. If unsure, press Now and compare the digit count.

In JavaScript, the Date constructor takes milliseconds, so seconds must be multiplied: new Date(sec * 1000). Going the other way, use Math.floor(Date.now() / 1000). Passing Date.now() where seconds are expected produces a value about 1000 times too large.

Time zones: local time is rendered in the browser's time zone, with daylight saving handled by the browser's rules for that zone; the UTC and ISO lines are always UTC, and ISO looks like 2026-10-25T07:30:00.000Z. There is no time-zone switcher, so the same timestamp can show a different local time on another machine while UTC stays the same.

Do not use 0 as a missing value. 0 is a valid instant, 1970-01-01T00:00:00Z; use null for missing and check for it explicitly.

The year 2038 problem comes from storing Unix seconds in a signed 32-bit integer, whose maximum 2,147,483,647 corresponds to 2038-01-19T03:14:07Z. This tool uses JavaScript Number and Date (double precision), so it is not affected and Date reaches roughly ±8.64e15 milliseconds. Your database column or server may still be 32-bit, so confirm that separately before writing.

• 10 digits is seconds, 13 is milliseconds — a factor of 1000
• Multiply seconds by 1000 for JavaScript Date
• Local time follows the system zone; UTC is fixed
• 0 is a valid instant; use null for missing

Alternatives and limits

On the command line, date -u -r 1761328800 (macOS) or date -u -d @1761328800 (Linux) prints UTC directly, and date -u +%s gives the current seconds. Useful for batch conversion in scripts.

In code, use time-zone-aware APIs: Python's datetime.fromtimestamp(ts, tz=timezone.utc), Java's Instant.ofEpochSecond, or Go's time.Unix. They handle zones and formatting correctly.

To see wall-clock time in New York, London, and Tokyo at once, or to parse an ISO string with an offset such as 2026-10-25T15:30:00+08:00, use a tool with time-zone selection or a date library. This tool accepts only numeric timestamps and a local datetime input, and does no date arithmetic.

• Batch conversion in scripts → date
• Application code → a zone-aware date API
• Multiple zones or offset-bearing ISO strings → a dedicated tool
• No offset parsing and no time-zone switching here