Timestamp Converter

Practical Example

Convert a Unix timestamp from logs into a readable date, or turn a scheduled time into a timestamp value for configuration. Check whether the source uses seconds or milliseconds because the result changes dramatically.

What is a Unix Timestamp?

A Unix timestamp (also called Epoch time or POSIX time) represents the number of seconds elapsed since 1970-01-01 00:00:00 UTC. It is the most widely used time format in computing — found in server logs, database records, JWT token claims, cron schedulers, and cross-service API communication.

Most systems use 10-digit timestamps (seconds), while JavaScript's Date.now() and some APIs return 13-digit timestamps (milliseconds). This tool automatically detects the format and converts in both directions. All processing runs in your browser.

Time Format Comparison

Unix Timestamp is a single integer, timezone-independent, and easy to compute with (simple arithmetic for duration calculations). However, it is not human-readable.

ISO 8601 (2024-01-15T09:30:00Z) is the standard interchange format for APIs and logs. It includes timezone information and is human-readable. The Z suffix indicates UTC.

RFC 2822 (Mon, 15 Jan 2024 09:30:00 +0000) is used in email headers and HTTP headers. More verbose but includes day-of-week information.

Practical Use Cases

JWT Token Debugging — JWT claims exp (expiration) and iat (issued-at) are Unix timestamps in seconds. Convert them to verify whether a token is expired or to check how long it remains valid.

Incident Timeline Analysis — During outage investigations, convert event timestamps from logs into UTC and local time views to build accurate timelines across services in different time zones.

Scheduler Configuration — Cron jobs, scheduled tasks, and rate limiters often use Unix timestamps. Convert target dates to timestamps for precise scheduling.

Database Audits — Verify that all tables use consistent precision (seconds vs milliseconds). Mixing 10-digit and 13-digit values in the same system is a common source of bugs.

Common Pitfalls

Second vs Millisecond Confusion — Treating a 13-digit millisecond value as seconds shifts the date by decades (e.g., year 2001 vs year 53,000+). This tool auto-detects based on digit count, but always verify in your own code.

Timezone Mismatch — Comparing a local datetime input directly with a UTC timestamp without normalization produces incorrect results. Always convert to the same timezone before comparison.

Y2K38 Problem — Systems using 32-bit signed integers for Unix timestamps will overflow on January 19, 2038. Most modern systems use 64-bit integers, but legacy embedded systems and older databases may be affected.

Seconds or Milliseconds? — Instant Diagnosis

Count the digits. As of today, 10 digits means seconds, 13 means milliseconds (16 is microseconds, 19 nanoseconds). JavaScript Date.now() returns milliseconds while Unix tools and Python time.time() think in seconds, so a factor-of-1,000 error is the most common cross-language bug. If a conversion lands near 1970 or in the year 52,000, the unit is wrong.

The Timezone Trap — Store UTC, Display Local

A timestamp has no timezone. 1721000000 is the same instant everywhere on Earth; only its display as a wall-clock time depends on the zone. The working rule: store, transmit and log in UTC (the raw timestamp); convert to local time only at the display layer. The rule most often breaks when local-time strings get stored in databases — data that becomes unresolvable after server moves or DST shifts. This, plus the 2038 32-bit overflow problem, is covered in the Unix timestamp guide.

FAQ