Unix Timestamp Converter Guide: Epoch Time, Seconds, and Milliseconds

Unix timestamps appear everywhere: APIs, JWT claims, database records, logs, analytics systems, webhooks, scheduled jobs, and cloud infrastructure.

A timestamp such as 1788611400 is compact and machine-friendly, but it is difficult to understand without converting it into a human-readable date.

Duck Cloud's Unix Timestamp Converter converts epoch timestamps into readable UTC and local dates directly in your browser.

What is a Unix timestamp?

A Unix timestamp represents elapsed time relative to the Unix epoch, which begins at:

1970-01-01 00:00:00 UTC

Many systems represent the elapsed time in seconds.

That makes timestamps convenient for sorting, comparing, transmitting, and storing dates without formatting them as language-specific strings.

Seconds vs milliseconds

One of the most common timestamp bugs is confusing seconds with milliseconds.

Many APIs use seconds:

1788611400

JavaScript's Date constructor commonly expects milliseconds:

new Date(1788611400 * 1000)

A millisecond timestamp is roughly 1,000 times larger:

1788611400000

If your converted date appears near January 1970 or thousands of years in the future, check the unit first.

UTC vs local time

A Unix timestamp represents an instant in time. It does not inherently store a display timezone such as Asia/Yangon or America/New_York.

The same instant can be displayed differently depending on the timezone.

For debugging distributed systems, UTC is usually the clearest reference because servers in different regions can compare the same value.

For user interfaces, convert that instant into the user's intended timezone.

The Unix Timestamp Converter shows both UTC and local interpretations so you can compare them quickly.

Why APIs use epoch timestamps

Numeric timestamps are useful because they are:

• compact;
• easy to compare;
• language-independent;
• unaffected by date-format ambiguity;
• convenient for expiration calculations.

A system can ask whether expires_at < current_time without parsing a human-formatted date.

JWT expiration timestamps

JWT claims such as exp, iat, and nbf commonly use NumericDate values based on Unix time in seconds.

If authentication appears to expire too early or too late, decode the test token with the JWT Decoder, check its timing with the JWT Expiry Checker, and convert the exact value with the Unix Timestamp Converter.

Do not treat decoding as signature verification. These tools are useful for inspection, while production authentication should use maintained verification libraries.

Database timestamps

Databases may store time as:

• native timestamp/date types;
• Unix seconds;
• Unix milliseconds;
• ISO 8601 strings.

Native date/time types are often easier for database queries and date arithmetic, while epoch values are useful in some event and cross-platform systems.

Whatever representation you choose, document whether the unit is seconds or milliseconds.

A column called created_at_ms is much less ambiguous than one called simply timestamp.

Debugging logs

When a log contains only epoch time:

1. copy the exact numeric value;
2. identify whether it is seconds or milliseconds;
3. convert it;
4. compare UTC with the server's configured timezone;
5. line it up with request IDs, deployments, and related events.

This is especially useful when correlating application, proxy, database, and worker logs.

Timezone mistakes

A common application bug is converting an instant to local time and then treating that local representation as UTC again.

Another common problem is saving a timestamp together with an incorrect timezone offset.

A safer pattern is:

• store an unambiguous instant;
• transmit standardized timestamps;
• convert to local presentation only at the display boundary.

For business schedules, also keep the intended IANA timezone when the local clock time itself matters.

Timestamps in cron debugging

Cron schedules and timestamps solve different problems.

Cron describes when recurring work should run. Unix time identifies a specific instant.

When a scheduled job runs unexpectedly, use the Cron Expression Parser to inspect the schedule and the Unix Timestamp Converter to examine actual logged run times.

Timestamp troubleshooting checklist

• Confirm seconds vs milliseconds.
• Convert the value to UTC.
• Compare the expected local timezone.
• Check whether daylight-saving rules affect the displayed local time.
• Verify the server clock.
• Review serialization between languages and databases.
• Use explicit field names when storing epoch units.
• Avoid manually adding fixed timezone offsets.

Unix timestamps are simple once the unit and timezone responsibilities are clear. Treat the number as an instant, convert it deliberately, and keep display formatting separate from storage and comparison logic.