Unix Timestamp Converter: Seconds, Milliseconds, UTC

A Unix timestamp converter turns an epoch value into a readable date. Use the FindUtils Unix Timestamp Converter to compare UTC, local time, and ISO output, after you confirm the input unit.

For example, 1788912000 seconds and 1788912000000 milliseconds both identify September 9, 2026, at midnight UTC. This guide explains those conversions, reverse conversion, and the current limits of the browser and API tools.

What does a Unix timestamp represent?

A Unix timestamp normally counts seconds from January 1, 1970, at 00:00:00 UTC. A millisecond timestamp uses the same origin with 1,000 units per second. Ordinary Unix time does not count leap seconds as additional elapsed seconds. See the POSIX time rationale.

The unit belongs to the data contract. A number alone does not identify seconds or milliseconds. JavaScript Date uses milliseconds, as the MDN Date reference explains.

Use a conversion when you need to inspect:

• An event time: Identify when a request or background task occurred.
• An API field: Compare a returned number with the expected calendar date.
• A log entry: Read an event in UTC before comparing it with another system.
• A date boundary: Check the exact instant that starts or ends a reporting period.

Do not treat a timestamp as proof that a device clock was correct. Conversion changes the representation of the supplied value.

How do you convert a timestamp to a date?

Confirm the unit, enter a clean integer, and compare the ISO result with an expected date. The browser tool updates its result when you change the input.

Step 1: Open the converter

Open the Unix Timestamp Converter. Select Timestamp to Date. If you start with an API response, use the JSON Formatter to locate the relevant field first.

Step 2: Confirm the input unit

Read the source field's documentation. For a contemporary date, seconds often have 10 digits and milliseconds often have 13 digits. These lengths are clues, not a format guarantee.

Step 3: Enter the complete integer

Enter 1788912000 without quotes, spaces, separators, or a unit suffix. The UTC result identifies September 9, 2026, at midnight. The ISO result is 2026-09-09T00:00:00.000Z.

Step 4: Compare the output representations

Read the UTC and ISO values first. The local result uses your browser's time zone. A local calendar date can differ from the UTC date without changing the represented instant.

Step 5: Keep the unit with the copied value

Record the input as 1788912000 seconds, or use a field name such as occurred_at_seconds. When you copy the ISO result, keep its final Z.

Which example values can you check?

These synthetic examples use explicit units and expected UTC results. They provide reference points for a conversion, rather than evidence about your own source data.

The last row preserves 123 milliseconds. Converting that value into an integer number of seconds removes this fraction. Keep the original value when you need the original precision.

For a JavaScript conversion with an explicit unit:

const seconds = 1788912000;
const milliseconds = seconds * 1000;
const iso = new Date(milliseconds).toISOString();
// 2026-09-09T00:00:00.000Z

Multiplication by 1,000 belongs at the seconds-to-milliseconds boundary. Do not apply it again to a value that already uses milliseconds.

How do you convert a date to a Unix timestamp?

The browser's Date to Timestamp form interprets the entered date and time in your local zone. It returns seconds and milliseconds. The form does not provide a UTC-zone selector.

1. Select Date to Timestamp.
2. Enter the intended calendar date yourself.
3. Enter the complete local clock time.
4. Copy the result with its seconds or milliseconds label.
5. Convert the copied result back to a date to check the instant.

Enter both fields even when they already contain values. The current initial values combine a UTC calendar date with a local clock time. Near a date boundary, that combination can identify the wrong day.

For an exact UTC date, use an explicitly qualified string in code:

const milliseconds = Date.parse('2026-09-09T00:00:00Z');
const seconds = Math.floor(milliseconds / 1000);
// milliseconds: 1788912000000
// seconds: 1788912000

Do not remove the Z from this example. JavaScript interprets a date-and-time string without an offset as local time. The Date.parse documentation describes this rule.

Which conversion method should you use?

Use the browser for a manual check of a known contemporary value. Use an explicit-unit conversion when your application needs repeatable parsing rules.

The REST reference and MCP reference document the programmatic interface. Its to_timestamp result uses whole seconds, while its ISO result can retain milliseconds.

The browser conversion code processes the entered values locally. This statement concerns conversion input. Read the Privacy Policy for website data practices. Use synthetic values when a real log contains private information.

What input mistakes should you avoid?

Most checks begin with three questions: which unit does the source declare, which zone does the date use, and what precision must survive?

Mistake 1: Treating unit detection as validation

The current browser tool treats input longer than 10 characters as milliseconds. It counts raw characters, including spaces and signs. Enter clean values and use explicit-unit code for unusual ranges or historical millisecond values.

Mistake 2: Adding a suffix or separator

Do not enter 1788912000s or 1,788,912,000. The converter uses permissive integer parsing. A displayed date does not prove that it accepted every character as intended.

Mistake 3: Reading local output as UTC

Compare the ISO result before you conclude that two systems disagree. Use the Timezone Converter when the task concerns a named destination zone.

Mistake 4: Losing fractional precision

The whole-second value for 1788912000123 milliseconds is 1788912000. A reverse conversion gives 1788912000000 milliseconds. The discarded 123 milliseconds cannot return automatically.

Mistake 5: Treating zero as missing

Zero identifies the Unix epoch. Define missing data separately, such as an absent field or a documented null. Do not replace a missing timestamp with zero unless that behavior is intentional.

Tools used in this guide

These tools support different parts of the date review:

• Unix Timestamp Converter: Inspect epoch values and local date input.
• Timezone Converter: Compare clock times across named zones.
• JSON Formatter: Read timestamp fields inside a JSON example.

FAQ

Q1: Does the Unix timestamp converter accept milliseconds? A: The browser tool uses input length to detect milliseconds. Its REST and MCP to_date mode accepts seconds. Confirm which interface you use.

Q2: Why does my timestamp show a date in 1970? A: Check whether a seconds value reached an input that expects milliseconds. For example, 1788912000 milliseconds identifies January 21, 1970, at 16:55:12 UTC.

Q3: Does changing the display zone change the timestamp? A: Displaying the same instant in another zone keeps the timestamp unchanged. Entering a local date without an offset is a different operation.

Q4: Can I use digit count to identify the unit? A: Only as an initial clue. Older millisecond values can be short, and later second values can exceed 10 digits. The source contract decides the unit.

Q5: Does the date form use UTC? A: No. The browser form uses local time. Use a qualified date string with Z when you need an exact UTC input.

Q6: Does a successful conversion prove the input is valid? A: No. The current parsers accept some partial numeric input. Validate the full field, unit, and accepted range in the receiving application.

Next steps

Use Unix timestamp seconds vs milliseconds to review a data exchange. It provides a contract table and a diagnostic sequence.

For a scheduling task, read the Timezone Converter guide. For a repeating task, read the Cron Expression Generator guide.