Unix Timestamp Converter

Server logs spit out Unix timestamps because they're efficient for machines, then you spend the rest of the day translating them into human-readable times in your head.

Paste a timestamp (seconds or milliseconds — the converter detects which based on magnitude) and get human-readable output in your local time, UTC, and ISO 8601. Or paste a date and get the timestamp. Conversions work in both directions and handle the boundary cases — negative timestamps (before 1970), the 2038 problem (32-bit signed int overflow), and the difference between 13-digit JS timestamps and 10-digit Unix ones.

The 2038 issue is worth knowing about even if it sounds far off: code that stores timestamps in signed 32-bit integers will overflow on January 19, 2038 at 03:14:07 UTC. Most modern systems use 64-bit, but legacy embedded systems and database schemas still pop up where this matters. The converter flags timestamps near that boundary.

A Unix timestamp counts seconds since 1970-01-01 00:00:00 UTC, the 'epoch.' This convention came from Unix in the early 1970s and stuck because it's simple, language-independent, and timezone-agnostic — a Unix timestamp uniquely identifies an instant in time without needing zone metadata. JavaScript's Date.now() returns milliseconds since epoch (13 digits), while most Unix tools use seconds (10 digits). The converter detects which based on magnitude: numbers under about 10^11 are seconds, larger ones are milliseconds.

The pain this addresses: server logs are full of Unix timestamps that you need to read as human times for debugging. '1709510400' is a real moment — but you can't read it directly. Pasting it into the converter shows '2024-03-04 00:00:00 UTC' or whatever your local zone is. This is the kind of micro-task that breaks debugging flow if you have to fiddle with date library docs every time. The converter is two clicks: paste, read.

Worked example: paste '1709510400.' Output: 'Mon, 04 Mar 2024 00:00:00 UTC.' In your local time zone (say, EST): 'Sun, 03 Mar 2024 19:00:00 EST.' In ISO 8601: '2024-03-04T00:00:00Z.' Now reverse: paste '2024-12-25 12:00:00' (assume UTC). Output: 1735128000. Both directions work, both formats are common in API responses and logs. The converter normalizes to whatever you ask for.

Where this gets historically interesting: leap seconds. Unix time officially ignores them — there have been 27 leap seconds added since 1972 to keep UTC synchronized with Earth's rotation, but Unix time pretends they don't exist. This means a Unix timestamp converted to UTC can be off by up to 27 seconds from a 'true' atomic time. For most uses, this doesn't matter. For scientific timekeeping, GPS, or precision navigation, you need TAI (International Atomic Time) which doesn't skip leap seconds. Modern systems mostly handle this transparently; if you're working at sub-second precision, look up the difference between Unix time, UTC, and TAI for your specific use case.