Unix timestamps are one of the most important data formats in programming — they appear in database records, API responses, log files, file system metadata, authentication tokens, and countless other places. The format is elegantly simple: a single integer representing seconds (or milliseconds, microseconds, or nanoseconds) since January 1, 1970. Yet working with timestamps correctly is surprisingly tricky because of timezone handling, precision mismatches between systems, and DST edge cases. The sections below explain what Unix time is and why it exists, how to handle timezones correctly when converting, and the common bugs that catch developers even after years of experience.
What Unix Time Is and Why It Exists
Unix time, also called Epoch time or POSIX time, is the number of seconds elapsed since January 1, 1970 00:00:00 UTC — a reference point called the Unix epoch. Negative values represent dates before that epoch, positive values represent dates after. The format originated in the early 1970s when Unix systems needed a compact, timezone-independent way to store timestamps in file system metadata and log records. A single 32-bit signed integer could represent dates from 1901 to 2038, which seemed sufficient at design time but creates the famous Year 2038 Problem as that range expires. Modern systems use 64-bit integers, pushing the expiration out to year 292 billion. The elegance of Unix time is that it has no timezone, no DST, no leap seconds (officially — most implementations simply smear the rare leap seconds), and no calendar complexity. It's a monotonically increasing counter that unambiguously identifies a specific moment. Time zones, calendar dates, and human-readable formats are all layered on top at display time. This makes Unix time the preferred format for comparisons (`if (tokenExpiresAt < now)`), sorting, and storing timestamps in databases across distributed systems that span timezones. Human-readable formats like `2024-04-21 11:58:41` are derived from the stored Unix value only when displaying to a user.
Timezone Handling — The Subtle Part
A Unix timestamp itself has no timezone — it represents a specific moment in absolute time. When you convert to human-readable form, you pick a timezone for display, and the same timestamp produces different local times in different zones. For example, 1713711521 seconds after epoch is 15:58:41 UTC, but that same moment is 11:58:41 EDT (America/New_York, UTC-4), 08:58:41 PDT (America/Los_Angeles, UTC-7), 00:58:41 JST the next day (Asia/Tokyo, UTC+9), and countless other local times around the globe. Getting this right in practice requires IANA timezone names like `America/New_York` rather than fixed offsets like `UTC-05:00`, because IANA names encode the full DST history. Saying "4 PM EST on July 15, 2024" is actually ambiguous because Eastern Time observes DST and July dates are in EDT (UTC-4), not EST (UTC-5). IANA timezones resolve this ambiguity automatically — the browser's Intl API and server-side libraries like pytz, moment-timezone, and Java's ZoneId all use the IANA database and handle historical DST transitions correctly. This converter uses the browser's built-in Intl.DateTimeFormat with full IANA timezone support, which means it produces correct local times for any valid zone including historical dates going back to 1970 or earlier.
The Common Bugs That Catch Even Experienced Developers
A handful of timestamp bugs appear so often they're worth internalizing as a checklist. First, seconds vs milliseconds confusion: JavaScript's Date object works in milliseconds while Python's time.time() works in seconds, and accidentally mixing them multiplies or divides your dates by 1000. Check the magnitude: 10-digit numbers are seconds, 13-digit are milliseconds, 16-digit are microseconds. Second, timezone assumption in parsing: the string "2024-04-21 11:58:41" has no timezone, and different parsers default to different assumptions. JavaScript's Date constructor treats it as local time; Python's datetime.fromisoformat treats it as naive (no timezone). Always attach an explicit timezone to ambiguous strings before parsing. Third, DST edge cases at spring and autumn transitions: 2:30 AM on the spring-forward day doesn't exist in most US timezones (the clock jumps from 1:59 to 3:00), and 1:30 AM on the fall-back day exists twice. Date arithmetic that adds or subtracts hours across a DST boundary can produce surprising results unless you use IANA-aware libraries. Fourth, "now" drift across servers: server clocks drift by milliseconds or seconds, so tokens generated on one server and validated on another need a tolerance window. Fifth, leap seconds: rarely relevant in practice because most systems smear them, but critical for precise scientific or financial applications. This converter sidesteps most of these by using the browser's well-tested Intl APIs, but the underlying concepts still matter when writing code that consumes converted values.