Timestamp Converter

A Unix timestamp (also called epoch time or POSIX time) is an integer counting the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — the Unix epoch. It has no timezone embedded; it always represents a fixed, unambiguous point in time regardless of where you are.

The format is universal: every major language, database, and operating system understands it. This makes Unix timestamps the standard mechanism for storing and comparing times across heterogeneous systems.

Because it is a plain integer, time arithmetic is trivial: add 3600 to advance one hour, subtract two timestamps to get elapsed seconds, compare two timestamps with a simple integer comparison.

The digit count is the fastest way to tell seconds from milliseconds at a glance.

A 10-digit value is seconds. Current epoch time in seconds has been 10 digits since 2001 and will remain 10 digits until the year 2286. Server-side runtimes (Unix kernel, Go's time.Now().Unix(), Python's time.time(), PostgreSQL's EXTRACT(epoch …)) all return second precision.

A 13-digit value is milliseconds. JavaScript's Date.now(), browser Performance APIs, and many JavaScript libraries return milliseconds. A 13-digit value is simply the 10-digit value multiplied by 1000.

If you see year 1970 (or wildly wrong year) when you expected 2020+, you most likely passed a millisecond timestamp to code expecting seconds — divide by 1000. Conversely, if you see year 55000+, you passed seconds to code expecting milliseconds — multiply by 1000.

When you need the current epoch time — to compare against a stored value, set a token expiry, or verify a cron schedule — each environment exposes it differently.

JavaScript gives millisecond precision with Date.now(). Divide by 1000 and floor to get seconds, which is what most server-side systems and JWT fields (exp, iat) expect.

JSON Web Tokens use Unix timestamps in seconds for two standard claims: iat (issued at) records when the token was created; exp (expires at) records when it becomes invalid. Both are plain integers in the JWT payload.

To check whether a token has expired: extract the exp value from the JWT payload, paste it here, and compare the resulting date and time to now. If exp is in the past, the token is expired and any request using it will be rejected.

A common source of bugs: generating exp by calling Date.now() (which returns milliseconds) without dividing by 1000. The resulting token carries a value like 1700000000000 as the expiry, which the server interprets as seconds — placing expiry in the year 55812. The token never expires during testing, masking the bug until production code uses a strict validator.

REST API responses and server logs are the most common places developers encounter raw timestamps they need to interpret on the fly.

APIs: when a JSON field named created_at, updated_at, timestamp, or issued_at contains a large integer, it is almost always a Unix timestamp. The digit count tells you seconds (10 digits) vs milliseconds (13 digits). GitHub, Stripe, and AWS all use Unix timestamps; Twitter historically used milliseconds.

Server logs: nginx, Apache, syslog, and most structured loggers record event times as Unix timestamps. When tracing an incident, convert the target time window to a Unix range first, then filter logs by numeric range — far faster than parsing date strings.

Databases: PostgreSQL stores timestamps as TIMESTAMPTZ internally; EXTRACT(epoch …) converts to a Unix integer. MySQL's UNIX_TIMESTAMP() does the same. SQLite has no native timestamp type — values are typically stored as Unix integers directly, and queries rely on integer comparison.

UTC output is stable and timezone-independent. Use it when comparing timestamps across machines or systems in different regions.

Local time output reflects your browser's configured timezone. This is what you see on your machine, and it may differ by hours from what a server in another region records for the same timestamp.

The tool shows both formats simultaneously so you can verify the relationship without converting manually.

Practical rule: store and transmit timestamps as UTC integers. Convert to local time only at the display layer, as close to the user as possible.

Off-by-1000: the most frequent timestamp bug. Occurs when a millisecond value is used where seconds are expected, or vice versa. Symptoms: dates that land in 1970, or dates tens of thousands of years in the future.

Timezone assumption: constructing "2024-01-15" without specifying UTC and passing it to new Date() in JavaScript results in local-timezone interpretation. This produces a different Unix timestamp on every machine in a different timezone. Always append Z or +00:00 when the intent is UTC.

Float truncation: Python's time.time() and JavaScript's performance.now() return fractional seconds. If you need an integer (most storage contexts do), use math.floor() or int() explicitly — do not rely on implicit conversion, which may round up.

DST gaps and overlaps: when converting a wall-clock time in a DST-observing timezone to UTC, one hour per year is ambiguous (clock goes back) or does not exist (clock goes forward). Storing UTC integers avoids this class of bug entirely.

Epoch time — also called Unix time or POSIX time — is the number of seconds elapsed since 1970-01-01 00:00:00 UTC, the moment chosen as the Unix epoch. Every conversion from epoch to timestamp anchors on this single fixed origin, which is why the format is unambiguous across machines, languages, and timezones.

The epoch was set when Unix was being developed in the early 1970s, and 1970-01-01 was chosen as a clean, recent boundary that would let the operating system store dates in a small signed integer for decades. The choice has stuck because it removed timezone ambiguity at the storage layer: an epoch value never needs an offset attached, so two systems comparing two integers will always agree on which one is earlier.

Negative epoch values are valid and represent times before 1970. For example, −86400 is 1969-12-31 00:00:00 UTC and −31536000 is 1969-01-01 00:00:00 UTC. Some historical archives, birth-date fields, and scientific datasets contain negative epoch values, so any robust converter should accept them rather than treating them as invalid input.

A handful of epoch values appear repeatedly in documentation, test fixtures, log files, and bug reports. Recognising them at a glance speeds up debugging when one shows up in an API response or a stack trace.

The reference table below covers the epoch origin, a clean billion-second mark from 2001, two recent round numbers, and the signed 32-bit maximum that triggers the Year 2038 problem. Together they bracket the range that production systems realistically operate within today.

Every mainstream language ships a built-in for epoch-to-date conversion. The snippets below convert the same epoch value (1700000000) to a human-readable UTC string so you can sanity-check output across environments before wiring conversion logic into your code.

JavaScript: Date.now() returns the current epoch in milliseconds. Multiply a seconds value by 1000 before passing to the Date constructor, then format with toISOString() for a stable UTC string. Use toLocaleString() if you instead want the browser's configured timezone.

Python: datetime.fromtimestamp accepts seconds. Pass tz=timezone.utc to keep the result anchored to UTC instead of the host machine's local timezone. Pair with .isoformat() to produce an ISO 8601 string suitable for logs or API responses.

Unix CLI: GNU date accepts the @ prefix to read an epoch value. On macOS and other BSD systems use date -r instead. Both print the timestamp in the shell's configured timezone — set TZ=UTC or pass -u for portable output.

Different ecosystems default to different precisions, and mixing them is the single most common source of timestamp bugs. The fastest rule of thumb: a 13-digit integer is milliseconds, a 10-digit integer is seconds. This holds for any value between roughly 2001 and 2286, which covers every realistic production timestamp.

Milliseconds by default: JavaScript (Date.now), Java (System.currentTimeMillis), C# (DateTimeOffset.ToUnixTimeMilliseconds), and the Web Performance API. Anything that originated in the browser or the JVM tends to use milliseconds because sub-second precision matters for UI and profiling.

Seconds by default: the Unix kernel (time(2)), Python (time.time and datetime.timestamp return seconds, with fractional precision available), Go (time.Now().Unix), Ruby (Time.now.to_i), Rust (SystemTime), and PostgreSQL (EXTRACT(epoch FROM …)). Most JWT libraries, OAuth flows, and HTTP cache headers also expect seconds.

Quick check before debugging further: count the digits. 1700000000 (10 digits) is seconds — November 2023. 1700000000000 (13 digits) is milliseconds — also November 2023. If you swap them by mistake, the seconds value gets read as 1970-01-20 (a few weeks after epoch) and the milliseconds value gets read as the year 55812.