Timestamp Converter (Unix ↔ ISO)

Timestamps are deceptively simple. The basic idea — a number representing the moment a thing happened — sounds straightforward until you start dealing with real systems and realise that almost every aspect of timestamp handling is either a confusion source, a portability issue, or a subtle bug waiting to happen. Unix seconds versus Unix milliseconds is the classic 1000x off-by-factor that shifts dates from 2024 to 56000 years in the future. Timezone interpretation is its own minefield: a database column called 'created_at' might be UTC, might be local time, might have an embedded offset, might be a string that gets re-parsed each time it's read. ISO 8601 helps but only when everyone agrees to use it consistently. This tool exists for the moments when you need to translate a timestamp between formats and confirm exactly what value it represents.

Unix seconds versus Unix milliseconds is the single most common source of timestamp bugs in JavaScript code. JavaScript's Date object uses milliseconds since the epoch as its native time format; almost every other language uses seconds since the epoch as its convention. A developer who pulls a timestamp from a Python API (seconds), creates a Date from it without converting, gets a date 50,000 years in the future. The reverse — pulling a JavaScript timestamp into a Python service that expects seconds — gets a date 50,000 years in the past. The tool here shows both interpretations side by side, which makes the off-by-1000 error visually obvious as soon as one of the dates is wildly wrong.

ISO 8601 is the format you should be using whenever timestamps need to travel between systems, and the format that actually saves debugging time when something goes wrong. The string '2024-03-15T14:30:00Z' is unambiguously a specific UTC moment that any compliant parser can read consistently. The string '2024-03-15 14:30:00' (no timezone) is ambiguous — it might be UTC, it might be local time, it might be the local time in some other timezone the originating system happens to use. The tool here always produces ISO 8601 with explicit timezone information, which makes the output immediately copy-pasteable into systems that expect unambiguous time formats.

Timezone handling is the area where timestamp bugs hide most often. The same Unix timestamp, displayed as a local-time string, looks completely different in New York versus London versus Tokyo. The rendering doesn't change the underlying value — the moment in time is the same — but the representation makes humans misread the timestamp if they don't notice the timezone hint. Production systems should universally use UTC for storage and convert to local time only at display, but plenty of legacy systems and ad-hoc scripts mix the two. The tool here makes the timezone explicit in every direction, which catches the 'this timestamp is in the wrong timezone' class of bug at a glance.

Daylight saving time is a sub-category of timezone confusion that bites specifically twice a year. The hour that gets repeated when clocks go back, and the hour that doesn't exist when clocks go forward, both produce timestamps that systems handle inconsistently. A meeting scheduled for 2:30 AM on the day clocks change might happen once, twice, or never depending on the timezone library used. The way to avoid this is keeping all timestamps in UTC internally and converting to local time only at display; the tool here demonstrates that pattern by always showing both representations, with UTC as the canonical form.

Common workflows where this tool earns regular use include debugging API responses (the API returned an exp claim, what date is that exactly?), inspecting log timestamps (an event happened at Unix 1710506400, what time is that in my timezone?), verifying cache expiration (this token expires at exp 1710513600, how long from now?), building test fixtures (I need a timestamp for 'one hour ago', what's the Unix value?), and reconciling reports across systems (these two values look different, are they actually the same moment in different timezones?). Each of these is a five-second operation with the right tool and a fifteen-minute cross-reference between Stack Overflow answers without one.