Confirm the producer
Find the emitting service, SDK, column, or serializer before changing units. Digit length is a lead, not proof.
Unix Expert
Unix timestamp debugger
Paste seconds, milliseconds, microseconds, nanoseconds, or an ISO date. The debugger identifies the unit, normalizes the instant, and generates implementation snippets.
Detected unitseconds
Digits10
Safe integeryes
Reason: 10 digits or fewer is usually Unix seconds.
Incident diagnosis checklist
Compare three renderings
Render UTC, application local timezone, and database/session timezone. A correct instant with the wrong display zone is a different incident from a bad epoch unit.
Look for decade drift
1970-era output usually means seconds were passed where milliseconds were required. Far-future dates often mean milliseconds were treated as seconds.
Preserve the raw value
Copy the original field and type. JSON numbers, CSV exports, and browser devtools can already round 16/19-digit values.
Production storage playbook
JavaScript / TypeScript
Date stores milliseconds in a Number. Keep µs/ns as string or BigInt; serialize high precision as strings in JSON.
PostgreSQL
Use TIMESTAMPTZ for instants or BIGINT for raw epoch units. to_timestamp() expects seconds; divide µs/ns deliberately.
MySQL
FROM_UNIXTIME() expects seconds. Prefer TIMESTAMP/DATETIME(6) for readable instants or BIGINT for raw epoch values.
Go
time.Time carries nanoseconds; build with time.Unix(seconds, nanos). Store protobuf-style seconds+nanos when crossing JSON boundaries.
Java
Use Instant.ofEpochSecond(seconds, nanos). Avoid java.sql.Timestamp surprises around legacy timezone/session handling.
Python
Use timezone-aware datetime.fromtimestamp(seconds, tz=timezone.utc). Keep integer µs/ns outside float timestamps when exactness matters.
Log and database field heuristics
Field names
created_at/updated_at often mean ISO or SQL timestamp; *_ms, elapsed_ms, duration_ms indicate milliseconds; *_us/µs and *_ns indicate high precision.
Columns
BIGINT epoch columns need a documented unit. TIMESTAMP without time zone can be session-local in SQL tooling; TIMESTAMPTZ represents an instant.
Event streams
Kafka, protobuf, OpenTelemetry, Go, and Java traces often carry nanoseconds or seconds+nanos pairs. Do not coerce them through JSON Number.
Ranges
Current seconds are 10 digits, ms 13, µs 16, ns 19. Values near 2147483647 should trigger a 2038 path check.
Implementation snippets
2038 boundary
Signed 32-bit Unix seconds overflow after 2038-01-19 03:14:07 UTC. Modern 64-bit systems are not limited by this boundary, but old C APIs, embedded systems, and database schemas can still break.
32-bit max second
2147483647
2038-01-19T03:14:07.000Z
One second later
2147483648
2038-01-19T03:14:08.000Z
Precision + storage boundaries
Unit detection
10 digits ≈ seconds, 13 ≈ milliseconds, 16 ≈ microseconds, 19 ≈ nanoseconds. Length is a heuristic; confirm the producer contract.
JS safe integer
Numbers above Number.MAX_SAFE_INTEGER (9,007,199,254,740,991) cannot represent every µs/ns value. Keep µs/ns as string, BigInt, or seconds+nanos.
Database pitfalls
PostgreSQL to_timestamp() and MySQL FROM_UNIXTIME() take seconds. Store high-precision epochs as BIGINT or TIMESTAMPTZ; avoid local-time TIMESTAMP surprises.
2038 boundary
2147483647 is 2038-01-19T03:14:07Z. Any signed 32-bit seconds path can overflow one second later.
Unix Expert FAQ
How do I know if a timestamp is seconds or milliseconds?
Current Unix seconds are usually 10 digits, while JavaScript milliseconds are usually 13 digits. If a date lands in 1970 or far in the future, the unit is probably wrong.
Why are microseconds and nanoseconds risky in JavaScript?
They often exceed Number.MAX_SAFE_INTEGER. Use strings, BigInt, or split seconds+nanos to avoid silently losing precision.
Does timezone change a Unix timestamp?
No. Unix time represents one instant. Timezone only changes the human-readable display.
What is the 2038 problem?
Signed 32-bit Unix seconds overflow after 2147483647. Old systems may wrap to a negative date even though modern 64-bit systems are safe.