Skip to main content

Unix Timestamp Converter

What it does

The Unix Timestamp Converter handles the everyday “what time was that, exactly?” question that comes up in log files, API responses, and database fields. Type a Unix timestamp and the tool shows the corresponding moment in seconds, milliseconds, ISO 8601, RFC 2822, local time, UTC, day of week, and a relative phrase like “3 hours ago”. Type a date and the timestamp follows. The current epoch second is pinned to the top so you can grab “now” without leaving the page.

Common situations

You’re reading production logs and need to translate a 1700000000 timestamp into “when did this actually happen?”. Most logging systems write Unix seconds because they sort lexicographically and survive timezone changes. Reading them back as a human is what this tool exists for.

You’re debugging a failure that occurred at a specific moment and need to find the relevant log entries. The error reporter says “happened at 2026-04-25T14:23:00Z”; your log search needs Unix seconds. Convert once, search confidently.

You’re integrating with two APIs that disagree about timestamp format: one returns Unix seconds, the other returns milliseconds. Your code interprets one as the other and produces dates in 1970 or in the year 56,000. Spotting which is which by magnitude (≥10¹² is almost certainly milliseconds) takes seconds.

You’re auditing a token expiry policy. JWTs use exp and iat as Unix seconds; you want to know how long tokens actually live. Decoding via the JWT Decoder gives you the timestamps; this tool converts them to readable dates and shows the difference at a glance.

You’re scheduling future work: adding a launch date to a feature flag, setting an expiration on a promotional code, configuring a cron-equivalent for a specific moment. Pick the date, get the timestamp, paste into your config.

What you need to know

A Unix timestamp counts seconds (or milliseconds) since 00:00:00 UTC on 1 January 1970. JavaScript’s Date object handles the calendar arithmetic: leap years, leap seconds (which it ignores like everyone else), timezone offsets, daylight-saving transitions. The tool feeds the timestamp into a Date and asks for each format’s representation.

The auto-detect for seconds vs. milliseconds is a magnitude check: Math.abs(n) >= 1e12 is treated as milliseconds. That threshold maps to early November 2286 in seconds, which is far enough in the future that any real-world timestamp under that value is almost certainly seconds.

Formats you will encounter:

  • Unix seconds: most languages, databases, Stripe, Unix tools. 10 digits for current dates.
  • Unix milliseconds: JavaScript’s Date.now(), Redis Streams, some newer APIs. 13 digits for current dates.
  • ISO 8601: 2026-04-25T14:23:00Z (with timezone) or 2026-04-25T14:23:00 (local). The unambiguous human-readable interchange format.
  • RFC 2822: Sat, 25 Apr 2026 14:23:00 +0000. Used in HTTP headers and email.

Time zone awareness is the trap. A Unix timestamp is always UTC. The local time displayed depends on the viewer’s clock. When sharing a moment across systems or with another human, ISO 8601 with explicit offset (2026-04-25T14:23:00+01:00) is the unambiguous form. “Wednesday at 3pm” without timezone is meaningless across distributed teams.

Daylight-saving transitions create ambiguous local times. In London on the last Sunday of October, the clock goes from 2:00 BST back to 1:00 GMT, meaning 1:30 happens twice. Local-time strings during these windows are ambiguous; UTC and Unix timestamps remain unambiguous. Always store and exchange in UTC; convert to local only at the display layer.

Leap seconds are ignored by Unix time and by every major language’s Date implementation. They exist (occasional one-second adjustments to keep UTC aligned with astronomical time) but are not represented in Unix epoch. For most software, this does not matter; for high-precision astronomy or financial trading, it occasionally does.

For dates before 1970, timestamps go negative. Most APIs do not handle these correctly. A negative timestamp arriving in production is usually a bug. The tool handles them, but be cautious about generating them deliberately.

Frequently asked questions

What is a Unix timestamp?

A count of seconds (or milliseconds) since 00:00:00 UTC on 1 January 1970. The standard way to represent moments in computing: sorts naturally, survives timezone changes, language-independent.

How do I convert a Unix timestamp to a date?

Pass it through the language’s standard date function. JavaScript: new Date(seconds * 1000). Python: datetime.fromtimestamp(seconds). Most languages have an equivalent. The tool here does it for you when you don’t have the language to hand.

What’s the difference between Unix seconds and milliseconds?

Same epoch (1970-01-01 UTC), different unit. Seconds is the original Unix convention; milliseconds is JavaScript’s preferred unit. Modern dates in seconds are 10 digits; in milliseconds, 13 digits.

How do I get the current Unix timestamp?

Math.floor(Date.now() / 1000) in JavaScript for seconds. time.time() in Python for seconds (with decimal precision). The tool’s “Right now” display gives you the value without typing.

Why are my JavaScript Date and database timestamp differing by 3600 seconds?

Daylight-saving transition or timezone offset. The database is probably storing UTC; JavaScript may be displaying local. Specify timezone explicitly when comparing: new Date(timestamp).toUTCString() forces UTC display.

What’s ISO 8601?

The international standard for date and time formatting. 2026-04-25T14:23:00Z (Z = UTC) or 2026-04-25T14:23:00+01:00 (with offset). The unambiguous form for sharing dates across systems.

Will Unix timestamps overflow in 2038?

32-bit signed Unix timestamps overflow on 19 January 2038. 64-bit timestamps (used by all modern systems) overflow in roughly 292 billion years. Most production systems migrated to 64-bit by the 2010s; legacy embedded systems and old C code may still be vulnerable.

How do I convert between time zones?

Convert to UTC first, then to the target timezone. The IANA timezone database (Europe/London, America/New_York, etc.) is the canonical source for offset rules including DST. JavaScript’s Intl.DateTimeFormat and Python’s zoneinfo handle this correctly.

Common problems

Problem: My timestamp shows the date “1970-01-21”.

You’re interpreting milliseconds as seconds (or vice versa). 1970-01-21 means the timestamp is being multiplied by 1000 when it shouldn’t be. Check the unit your source uses.

Problem: Dates display correctly on my Mac but wrong on the CI server.

Different system timezones. Tests should use UTC explicitly to be reproducible. process.env.TZ = 'UTC' in Node, equivalent in other runtimes.

Problem: Daylight-saving transition produces a one-hour gap or duplication.

Local time is ambiguous during DST transitions. Use UTC for storage and computation; only convert to local for display. Most “off by one hour” bugs trace to this pattern.

Problem: Timestamp comparisons fail despite identical values.

Type confusion. JavaScript Date objects compare by reference, not value. Use .getTime() to get the numeric timestamp, then compare numbers. Or use date library helpers that handle this.

Problem: A timestamp from an old log file shows a date in the future.

The log probably uses milliseconds where you assumed seconds. Or the source clock was misconfigured at the time. Check the magnitude: anything ≥10¹² for “current” timestamps is milliseconds.

Quick guides

JavaScript: Date.now() returns milliseconds. Math.floor(Date.now() / 1000) for seconds. new Date(timestamp_ms) parses, .toISOString() formats. Always work in UTC; convert at the display boundary.

Python: time.time() returns seconds (with decimal). datetime.now(timezone.utc) for timezone-aware now. datetime.fromtimestamp(seconds, timezone.utc) to parse.

SQL: Most databases have native timestamp types. EXTRACT(EPOCH FROM timestamp_column) in PostgreSQL. UNIX_TIMESTAMP(datetime) in MySQL. Always store as UTC.

Tips

  • Default to seconds when storing timestamps. Most languages, databases, and tooling expect them. Convert to milliseconds only at the JavaScript boundary.
  • The “Use now” button generates the current second. If you need millisecond-precise timestamps for tests or fixtures, multiply the displayed seconds by 1000 explicitly.
  • For dates before 1970, timestamps go negative. The tool handles them, but most APIs do not. A negative timestamp arriving in production is usually a bug.
  • The relative time (“3 hours ago”) is computed against the live “now” at the top, which updates every second. If you leave the tool open, the relative time stays current.
  • Daylight-saving boundaries make some local-time strings ambiguous. ISO 8601 with explicit timezone offset (2026-04-25T15:30:00+01:00) is the unambiguous form to copy when sharing a time across systems.
  • For human-readable display, prefer relative time (“3 hours ago”) for recent events and absolute time (“25 Apr 14:23”) for older ones. Most well-designed UIs combine both.

Related tools in this suite

Part of the Developer Suite. The natural pairing is the Cron Expression Parser, because cron schedules and Unix timestamps are the two languages of automated scheduling. The JWT Decoder is the most-used place where you will paste a timestamp from somewhere else (the exp and iat claims).

Take it further

Time handling is one of the genuine hard problems in software. Time zones, daylight-saving, leap seconds, ambiguous local times, system clock skew, NTP drift: production systems quietly accumulate edge cases the longer they live. The Knowledge Center covers the deeper patterns; the systems we build take time-handling decisions as first-class concerns rather than afterthoughts.