10 digits usually means Unix seconds for modern dates.
Unix Timestamp Converter
Paste a Unix timestamp to convert it into readable local time and UTC. You can also generate the current timestamp in seconds or milliseconds for logs, APIs, databases, and debugging.
How to use it
- Paste a timestamp or click current time.
- Choose seconds or milliseconds.
- Read the local date, UTC date, and ISO 8601 value.
Why Unix timestamps are useful
A Unix timestamp is timezone-neutral: it counts elapsed time since 1970-01-01 00:00:00 UTC. That makes it compact, sortable, and reliable for systems that need to exchange dates.
The main mistake is mixing seconds and milliseconds. JavaScript commonly uses milliseconds, while many APIs and databases use seconds.
Unix timestamps are common in APIs, logs, databases, analytics exports, JavaScript, Python, Linux tools, and incident timelines. They are compact, but difficult to read without converting them to local time or UTC.
The most common bug is using the wrong precision. A ten-digit value is usually seconds, a thirteen-digit value is usually milliseconds, and longer values are often microseconds or nanoseconds.
For debugging, compare the local time, UTC time, ISO 8601 string, and raw timestamp together. That makes it easier to spot timezone mistakes, daylight-saving confusion, and off-by-1000 errors.
When sharing timestamps with another developer, include the unit and an ISO value. A number alone can be ambiguous, but “1779244818 seconds / 2026-05-19T…” makes the intended moment much clearer.
Unix time is usually stored in UTC, but people read dates in local time. Showing both views side by side is important when a server is in UTC, a user is in California, and a support team is in Europe or India.
JavaScript returns milliseconds from Date.now(), PostgreSQL and many APIs often expose seconds, and some event streams use microseconds or nanoseconds. Checking the digit length before converting prevents many false dates.
The 2038 problem affects older systems that store Unix time as a signed 32-bit integer. Modern 64-bit systems avoid that limit, but old embedded devices, legacy databases, and file formats can still be affected.
Timestamp conversion is useful during incident response because logs from different systems often use different formats. One service may print ISO UTC, another may print epoch milliseconds, and a database export may contain seconds.
When investigating a bug, convert the timestamp and compare it with the user’s local timezone, the server timezone, and the deployment timeline. Many “wrong time” bugs are really display or unit bugs.
For analytics exports, a timestamp may represent event creation time, ingestion time, processing time, or reporting time. The number alone does not explain which one it is, so column names and documentation matter.
If you store timestamps yourself, keep the raw UTC timestamp and format it only at the display layer. That avoids losing information when users travel, change timezone, or view old events after daylight saving rules change.
How to tell which unit you have
13 digits usually means Unix milliseconds from JavaScript or browser APIs.
16 or 19 digits often come from high-precision databases, tracing tools, or event pipelines; digit count is a heuristic, so confirm against a known date.
Safe workflows for developers
- Normalize timestamps to UTC before comparing them across services or logs.
- Convert to a readable local time only at the presentation layer or when debugging a specific incident.
- If you are not sure about the unit, use auto-detect as a first pass, then confirm the result against a known event or log line.
Where timestamp mistakes usually happen
- Passing milliseconds into a system that expects seconds produces dates far in the future.
- Reading a local clock value as if it were UTC can shift events by hours.
- Copying timestamps around daylight saving changes is safe only if you stay in UTC until final display.
Worked examples
The timestamp 1717243200 is 2024-06-01 12:00:00 UTC when read as seconds.
The value 1717243200000 represents the same instant when read as milliseconds.
If a converted date lands in year 56387, you probably treated milliseconds as seconds.
FAQ
What is the Unix epoch?
It is 1970-01-01 00:00:00 UTC, the zero point from which Unix timestamps count.
Should I use seconds or milliseconds?
Use the unit expected by your system. JavaScript Date uses milliseconds, while Unix command-line timestamps are usually seconds.
How can I recognize seconds vs milliseconds?
Current timestamps in seconds are usually 10 digits, while milliseconds are usually 13. Treat digit count as a clue, not proof: confirm the converted date against a known event, log line, or expected range.
Why does my local time differ from UTC?
UTC is the global reference. Local time applies your timezone offset and may include daylight saving time.
What is ISO 8601 used for?
ISO 8601 is a readable, sortable date-time format used by APIs, databases, logs, and documentation.
What is the 2038 problem?
Some old systems store Unix time in a signed 32-bit integer, which overflows in January 2038. Modern 64-bit systems avoid this limit.