Timestamp Converter

What is a Unix timestamp?

A Unix timestamp counts the seconds since January 1, 1970, 00:00:00 UTC — also called the Unix Epoch. It's the most widely used time representation in computing because it's timezone-agnostic, simple to store as an integer, and trivially comparable and sortable.

Seconds vs milliseconds

Different systems use different precisions. Most POSIX/Unix APIs use seconds. JavaScript, Java, and many modern APIs use milliseconds. PostgreSQL and MySQL store as seconds with optional fractional parts. Redis uses milliseconds. This tool auto-detects by checking if the value exceeds 10¹² (the approximate millisecond timestamp for the year 2001).

Common uses

• Debugging API responses with timestamp fields
• Verifying JWT expiry (exp claim)
• Reading database timestamps
• Checking log file timestamps
• Setting cache or cookie expiration

How to read timestamps in different environments

In JavaScript, Date.now() returns milliseconds — divide by 1,000 to get seconds. In Python, time.time() returns seconds as a float. In PostgreSQL, EXTRACT(EPOCH FROM NOW()) returns seconds. In Redis, TIME returns seconds and microseconds as two integers. In Go, time.Now().Unix() returns seconds; time.Now().UnixMilli()returns milliseconds. This tool auto-detects the precision by checking whether the value looks like a 10-digit (seconds) or 13-digit (milliseconds) number — paste the raw value and it resolves the ambiguity.

The Y2K38 problem and modern systems

32-bit signed Unix timestamps overflow at 2,147,483,647 — January 19, 2038, at 03:14:07 UTC. Legacy systems using 32-bit integers for timestamps (some embedded systems, old C code, MySQL's TIMESTAMP type prior to MySQL 8.0.28) will either wrap to negative values or throw errors. Modern 64-bit systems extend the range to approximately 292 billion years in the future. PostgreSQL's TIMESTAMP type uses 64-bit and is safe. Most web applications built since 2010 use 64-bit integers and are not affected, but legacy systems still in production should be audited and upgraded before 2038.

ISO 8601 vs RFC 2822 — when to use which

ISO 8601 (2026-05-13T10:30:00Z) is the modern standard used by REST APIs, databases, HTML datetime inputs, and data interchange formats like JSON. It is lexicographically sortable and unambiguous across locales. RFC 2822 (Tue, 13 May 2026 10:30:00 +0000) is older, from the email protocol era, and is what JavaScript's Date.toUTCString() historically produced. Prefer ISO 8601 in all new systems — it is accepted byDate.parse(), Python's datetime.fromisoformat(), and virtually every date library. Use RFC 2822 only when integrating with legacy email systems or older APIs that require it.