Unix Timestamp Converter

Unix Timestamps: One Number, Every Time-Related Problem Solved (Mostly)

A Unix timestamp is a count of seconds since 1970-01-01 00:00:00 UTC. It's deceptively simple: one integer, no time zones, no formatting decisions, no calendar arithmetic. This is why every API, log file, database, and message queue uses timestamps internally. Strings get converted to timestamps on the way in and back to strings on the way out; in between, the system can do math, sort, compare, and store with predictable rules.

This converter handles every common conversion: epoch ↔ date strings, seconds ↔ milliseconds, UTC ↔ local time, ISO 8601 ↔ custom formats. The job is mechanical; the interesting part is knowing which representation to use where.

Why Timestamps Beat Date Strings Everywhere But the UI

Date strings are fragile:

• Locale ambiguity. 03/14/2026 is March 14 (US) or 3 April (EU). Without a parser that knows the format, you can't safely interpret it.
• Time zone ambiguity. 2026-03-14 09:00:00, but in which time zone? Most string formats leave this implicit, and the assumption changes between systems.
• Sortability. 12/01/2026 sorts before 02/01/2027 lexicographically, which is wrong chronologically.
• DST gotchas. Local time strings near DST transitions are ambiguous (does '2026-03-08 02:30' even exist?).

Timestamps solve all of these:

• One global integer count, no calendar interpretation needed.
• Sortable as numbers.
• No DST or time zone ambiguity.
• Trivial arithmetic, duration between two events is just a subtraction.

The trade-off: timestamps are unreadable to humans. So every system stores timestamps and displays formatted dates at the very last step (the UI). Inside your database, your API responses, your log lines, use timestamps or ISO 8601 with explicit UTC marker.

Seconds vs. Milliseconds vs. Microseconds vs. Nanoseconds

Most Unix systems use seconds (the original). JavaScript's Date.now() returns milliseconds. Postgres's timestamp columns store microseconds internally. Time-series databases (InfluxDB, Prometheus) often use nanoseconds.

Spotting them at a glance:

Conversion is just multiplication by 1000. The tool detects magnitude and converts automatically.

The Year 2038 Problem (Y2K38)

If a system stores a Unix timestamp as a signed 32-bit integer, the maximum value is 2,147,483,647, which corresponds to 2038-01-19 03:14:07 UTC. One second later, the integer overflows and becomes a large negative number, interpreted as 1901. Systems that still use 32-bit time_t will date-arithmetic incorrectly past that point.

Modern systems use 64-bit time_t (Linux ≥5.6, recent macOS, recent Windows). The vulnerabilities live in:

• Embedded firmware that hasn't been updated.
• Database systems with fixed-width 32-bit timestamp columns.
• Hand-rolled binary file formats from the 90s and 2000s.

If you're designing new systems in 2026, use 64-bit time everywhere; you won't see Y2K38.

ISO 8601: The Format You Should Default To

When you need a date as a string (logs, JSON APIs, file names), use ISO 8601:

Properties:

• Unambiguous. No locale interpretation; YYYY-MM-DD is fixed.
• Sortable. Lexicographic order = chronological order.
• Parseable everywhere. Every modern stdlib has parseISO/fromisoformat/Instant.parse.
• Human-readable enough to glance at in a log.

Avoid:

• US-style MM/DD/YYYY, locale-confusing.
• RFC 2822 (Tue, 14 Mar 2026 09:30:00 GMT), readable but verbose; only use where required by protocol (email, HTTP headers).
• Custom formats like 14-Mar-26, every parser handles them differently.

Time Zones: The Source of Most Bugs

Time zone bugs are common because there are too many things called 'time':

• UTC time, the global standard.
• System time, what new Date() returns; depends on server's TZ env var.
• User local time, what the user sees; depends on their browser/OS settings.
• Business time, fixed-zone time for a business (e.g., NYSE always uses ET).

Rules that prevent 90% of TZ bugs:

1. Store everything in UTC. Databases, logs, message timestamps, all UTC.
2. Transmit in UTC. API payloads with ISO 8601 + Z suffix.
3. Convert at the UI. Only when displaying to a user, convert to their local TZ.
4. Pin business-relevant zones. If a deadline is 'midnight Pacific', store both the UTC moment AND the original PT string, daylight savings transitions otherwise drift the meaning.

This tool shows both UTC and local interpretations of a timestamp side by side so you can spot mismatches.

Date Math: Do It in Milliseconds, Not Strings

Operations like 'add 7 days' or 'is X before Y' are painful on date strings (calendar arithmetic, time zones, DST). Done in millisecond timestamps, they're just integer arithmetic:

Caveat: 'add one day' isn't always 86,400,000 ms (DST transitions). For calendar-aware math (skip weekends, handle DST, leap years), use a library, date-fns, Luxon, Temporal API (now landing in browsers). Don't roll your own.

Common Workflows

1. Reading log timestamps. Paste 1710409200 from a log, see 2026-03-14T09:00:00Z and your local equivalent.
2. Crafting API filter URLs. Convert 'last 24 hours' to a timestamp pair: ?since=1710322800&until=1710409200.
3. Building cron expressions or backfills. Convert specific calendar dates to timestamps for batch range queries.
4. Debugging time zone bugs. Paste a timestamp from server logs and compare your local interpretation to the client's; mismatches reveal where the bug lives.
5. Counting elapsed time. Subtract two timestamps to get duration in seconds.

Privacy

All conversion runs in the browser using Date, Intl.DateTimeFormat, and Intl.RelativeTimeFormat, standard JavaScript APIs. No network requests. Safe for converting timestamps from internal logs without exposing them.