Unix Timestamp Converter: 10 vs. 13 Digits

An API returns 1640995200. What date is that? A log contains 1640995200000. Why does it have three extra digits? Then the converted date appears eight hours later than expected. Is the value wrong, or is the time zone different? All three questions lead to the same task: Unix timestamp conversion. This guide explains 10-digit and 13-digit timestamps with fixed examples and shows how to convert among local dates, seconds, and milliseconds.

If you only need the result, open the Unix timestamp converter. If you want to understand why the result looks the way it does, keep reading.

What Is a Unix Timestamp?

A Unix timestamp represents one specific instant as a number. Its epoch begins at 1970-01-01 00:00:00 UTC, and the familiar POSIX form counts seconds from that point. POSIX calls this “seconds since the Epoch” and accounts for each day as exactly 86,400 seconds. JavaScript Date values represent the same kind of timeline in milliseconds. See POSIX Seconds Since the Epoch and ECMAScript Date Objects for the formal definitions.

Numbers are convenient to sort, compare, and pass between systems. Instead of transferring a localized string such as “August 1, 2026 at 9:00 AM,” one service can send a timestamp and let the receiving side display it in the required time zone.

The distinction that prevents most mistakes is simple: a timestamp identifies an instant; a date string shows the wall-clock reading for that instant in a particular time zone. Shanghai and London can display different clock times for the same timestamp without disagreeing about the instant.

10-Digit vs. 13-Digit Timestamps

The two formats commonly seen in applications differ by one unit:

They differ by a factor of 1,000:

milliseconds = seconds × 1000
seconds = floor(milliseconds ÷ 1000)

JavaScript's Date.getTime() returns milliseconds since the epoch. To produce whole elapsed seconds, divide by 1,000 and round down. The MDN JavaScript Date documentation documents the same representation and conversion.

Digit counting is a useful shortcut, not a permanent format specification. Historical dates, far-future dates, and fractional values can break the usual 10-versus-13 pattern. When correctness matters, confirm the unit in the API contract. Yaya Tools asks you to choose seconds or milliseconds explicitly so the converter does not silently guess.

Convert a Unix Timestamp to a Date

The online timestamp converter turns an API or log value into a readable local date in three steps:

1. Paste the number into the “Timestamp → Date Time” field.
2. Select seconds or milliseconds.
3. Read the result in your device's local time zone.

Enter 1640995200 and select seconds:

• In UTC, the result is 2022-01-01 00:00:00.
• In China Standard Time (UTC+8), the result is 2022-01-01 08:00:00.

Nothing added eight hours to the instant. Both strings describe the same moment with different display zones. When debugging an API, first determine whether the backend returns a UTC instant or an already formatted local date before comparing values.

The tool also displays the current date plus current seconds and milliseconds at the top of the page. “Use Current Time” copies the current seconds value into the converter, which is handy for checking a system clock or creating test data.

Convert a Local Date to a Timestamp

For the reverse conversion, use the date-time picker or enter YYYY-MM-DD HH:mm:ss manually. The tool returns both seconds and milliseconds and provides a copy button for each value.

Suppose the device time zone is Asia/Shanghai and the input is:

2026-08-01 09:00:00

The results are:

Seconds:      1785546000
Milliseconds: 1785546000000
UTC:          2026-08-01 01:00:00

Here, 09:00 is a local wall-clock time. An HTML datetime-local control does not include a time-zone identifier; the browser interprets it in a local context. MDN's datetime-local reference explains that the control represents a local date and time rather than a zone-qualified instant.

If a manually typed value fails to parse, use the date-time picker. Browser handling of non-standard date strings can differ, while the control provides a more stable local date-time value.

Why a Conversion Is Off by Eight Hours

An eight-hour difference usually comes from treating UTC and UTC+8 as the same display zone, not from incorrect timestamp arithmetic.

UTC Was Displayed as Local Time

The value 2022-01-01T00:00:00Z uses Z to mark UTC. A browser in China Standard Time displays that instant as 08:00 on the same date.

A Zone-Free Date Was Treated as UTC

The string 2022-01-01 08:00:00 does not state a time zone. If one service reads it as Shanghai local time and another reads it as UTC, their timestamps differ by eight hours.

Storage and Presentation Were Mixed Together

Storing a common timestamp and presenting it in the reader's time zone is normal. Trouble starts when the displayed local string is written back as though it were UTC. Log the original timestamp, its UTC representation, and its local representation separately. One final formatted string is not enough evidence to find the faulty step.

Using Timestamp Conversion for API and Log Debugging

Timestamp conversion is most useful when it helps decide whether real data is plausible.

Check API Fields

Open the response in the JSON formatter, then copy fields such as created_at, expires_at, or updated_at into the timestamp converter. The article Debug Broken API JSON with a Formatter covers the JSON side of that workflow.

Check these points in order:

• Is the field measured in seconds or milliseconds?
• Does the converted value fall in a reasonable date range?
• Is an expiration time later than its creation time?
• Does the API contract specify UTC or a business time zone?

Check Scheduled Jobs

A timestamp confirms one instant; a cron expression describes a repeating schedule. When investigating a scheduled job, use the crontab execution-time tool to list upcoming runs, then compare those dates with timestamps from the job logs.

Check Encoded Payloads

Some tokens and API payloads use Base64 before exposing fields. Decode the content first with the Base64 encoding and decoding guide, then inspect its time values instead of guessing from an encoded string.

Common Errors and a Reliable Debugging Order

A reliable order is: check the unit, check the time zone, then check the date-string format. Do not begin by manually adding or subtracting eight hours. That can make one sample look correct while hiding the real time-zone contract.

Frequently Asked Questions

Does a Unix Timestamp Contain a Time Zone?

No. A timestamp identifies a common instant. The time zone affects only the date and clock time used to display that instant.

Is Every 10-Digit Timestamp in Seconds and Every 13-Digit One in Milliseconds?

That pattern is dependable for most current business dates, but it is still a heuristic. The API or field contract remains the authoritative source for the unit.

Does the Converter Upload My Data?

No. Yaya Tools performs date parsing and timestamp calculations in the current browser. The conversion operation does not send the input to a server.

Why Round Down When Converting Milliseconds to Seconds?

Dividing milliseconds by 1,000 can produce a fraction. Rounding down keeps only fully elapsed seconds and matches the common Math.floor(Date.now() / 1000) pattern.

Convert a Real Value Now

Keep the untouched value from an API response or log, then open the Unix timestamp converter and test the appropriate unit. Timestamps become straightforward once the unit and time-zone contract are explicit. Most timestamp bugs begin when one of those two details is left implicit.