Is This Long Number a Timestamp? Milliseconds vs Seconds

Last reviewed 2026-05-03. You pasted a 10-, 13-, 16-, or 19-digit number out of a server log, an API response, or a database row, and now you need to know what it is. This guide is the 30-second test - count the digits, sanity-check the year, route to the right converter.

The 30-second test: count the digits

The dominant Unix-timestamp formats encode time as a count of "ticks since 1970-01-01 00:00:00 UTC". The tick size differs - seconds, milliseconds, microseconds, nanoseconds - and that changes how many digits the number has at any given moment in 2026. Today (2026), here is the digit-count rule of thumb:

Why most numbers you see on the web are milliseconds

JavaScript's Date.now(), Java's System.currentTimeMillis(), and most modern JSON-emitting backends default to milliseconds since the Unix epoch. That moment - 2026-05-03 09:38:00 UTC - is 1777800999 in seconds (10 digits) but 1777800999000 in milliseconds (13 digits). The 13-digit form ends up in network responses, browser dev-tool consoles, log lines, and dashboards more than any other timestamp form, which is why the most common reader question on this cluster is "this is a 13-digit number, what date is it?"

That observation gives you a fast sanity check: if your number is 13 digits and starts with 1777, it is almost certainly a Unix millisecond from May 2026. If it starts with 16 or 17 in 2026, it is in the right ballpark. If it starts with 1 followed by anything else (e.g. 1234567890123), you should still convert it to a date and check the year before assuming - bogus test data often picks vanity numbers like 1234567890 which renders as 2009 (Friday 13 February).

When the number is NOT a timestamp

Several long numbers look like timestamps but are not:

• Snowflake / Twitter / Discord IDs (typically 18-19 digits). These encode a timestamp in their high bits but the low bits are worker IDs and sequence counters; treating the whole 19-digit number as a Unix nanosecond will produce a wildly wrong date. Snowflake decoding requires a bit-shift, not a divide.
• UUIDv7 (32 hex digits, but the first 12 hex characters encode milliseconds). If you have 32 hex characters formatted with hyphens, that is a UUID, not a timestamp - convert only the first 48 bits if you need the embedded time.
• Database BIGINT sequence IDs. These are auto-incremented integers and have no time component; they happen to grow into the 12-13 digit range as the sequence advances. Quick check: if the same column on adjacent rows differs by 1 (or by a small predictable step), it is a sequence, not a timestamp.
• Phone numbers stored as integers. A 10-12 digit number that starts with a country code prefix (e.g. 1212 for New York) may be a phone number rendered without separators. Convert and check: if the resulting year is before 1970 or after 2100, it is not a Unix timestamp.
• Account / order numbers. Padding-style numbers like 1000000123 (10 digits but not a Unix-second value) usually have a fixed-width prefix that betrays them - they don't grow steadily over time.

The cheapest disambiguation is to paste the number into the millisecond converter and look at the year. If the result is in 1970 (number was actually seconds, you treated it as ms) or in some far-future year like 56,000 (number was milliseconds, you treated it as seconds), the digit count will tell you which way to convert. If the result is plausible (2025-2027 for live data, 1990-2025 for historical data), you have your answer.

Quick conversion playbook

Three steps, no math:

1. Count digits. 10 digits = seconds; 13 = milliseconds; 16 = microseconds; 19 = nanoseconds; otherwise see the previous section.
2. Paste into the right converter. 13-digit numbers go straight into the millisecond-to-date converter. 10-digit seconds: append three zeroes (so 1777800999 becomes 1777800999000) and paste. 16-digit microseconds: drop the last three digits. 19-digit nanoseconds: drop the last six digits. The converter shows the resulting UTC date and your local date.
3. Sanity-check the year. If the year is unexpected (1970 or 56000), you converted in the wrong direction. Re-read the digit count and try again. If the year is plausible, you have the right value.

For the reverse problem - "give me the current Unix milliseconds so I can compare" - open the current Unix milliseconds tool; it ticks live and copies to the clipboard. Comparing two timestamps is the fastest way to confirm whether your number is "now-ish" or stale data.

FAQ

What about 11- or 12-digit numbers? They look almost like seconds.
Unix seconds will not produce 11 digits until the year 2286. Unix milliseconds were 12 digits between 2001 (10^12 ms = 31.7 years after 1970) and 2286. So a current-era 12-digit number is most likely a sequence ID or a phone number; an 11-digit number is almost certainly not a current Unix value of any kind.

The number is negative or starts with a minus sign. Is that a timestamp?
Yes - negative Unix timestamps are dates before 1970-01-01 UTC. -1000000000 seconds is 1938-04-24. Most language standard libraries handle negative seconds correctly; some web tools reject them. The millisecond converter will accept negative inputs.

Why does the same date give a different number on two systems?
The number itself is timezone-free (Unix time is always UTC). What differs is how each system renders the number into a human-readable string - one tool may pick UTC, another your local timezone. The underlying Unix integer is the same. If two systems disagree on the number for the same moment, one of them is using a different unit (seconds vs milliseconds) or a different epoch (e.g. Excel uses 1900-01-01 as its epoch, which is not Unix time).

Can I get fractional seconds out of a 10-digit Unix value?
No - a 10-digit seconds value has 1-second resolution. Fractional seconds (millisecond / microsecond precision) require the longer formats. If your data needs sub-second precision, you must be storing milliseconds (13 digits), microseconds (16), or nanoseconds (19). Storing only the integer seconds throws the precision away.

Is JavaScript new Date().valueOf() the same as Date.now()?
Yes. Both return Unix milliseconds. Date.now() is the modern, preferred form; new Date().valueOf() is older, slower (it allocates a Date object) but produces the same number.

Related

• Convert Milliseconds to Date - the action tool for 13-digit numbers; multiply 10-digit seconds by 1000 first.
• Get Current Unix Milliseconds - live ticker; useful for comparing your number against "now".
• Unix Timestamps Explained - the format reference: epoch, ISO 8601, RFC 2822, UTC vs local time, the three common timestamp pitfalls.
• MD5 vs SHA-256 when to hash - if your "number" turns out to be 32 or 64 hex characters, it is a hash, not a timestamp.
• CSV vs JSON data formats - the format your timestamp arrived in often hints at how it was encoded (ISO 8601 in CSV, milliseconds in JSON).