Unix Timestamp Converter: How to Read Epoch Time Correctly

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 - the Unix epoch. It does not account for leap seconds, which keeps the arithmetic simple: every day is treated as exactly 86,400 seconds. Positive numbers are moments after the epoch; negative numbers describe dates before it.

Because it is just an integer, a timestamp carries no time zone information of its own - it points at one exact instant everywhere on Earth simultaneously. The 'local' date and time you see for that instant depend entirely on where, or in what zone, you choose to display it. That single property is both the whole appeal of epoch time and the source of most confusion around it.

Storing time as a single number instead of a formatted string makes comparisons, sorting, and arithmetic trivial - timestampB - timestampA is just subtraction, no date-parsing library required. That efficiency is why epoch time shows up across almost every layer of the stack:

• REST and GraphQL APIs that return createdAt or updatedAt as raw numbers.
• JWT claims - exp, iat, and nbf are all Unix timestamps, decoded by tools like a JWT decoder.
• Database columns (created_at, expires_at) stored as integers for fast indexing and range queries.
• Server and application logs, where every line is stamped with the moment it was written.
• Cron schedules, cache expiry, and rate-limit windows, all of which compare against 'now' as a number.

Converting a timestamp to a date is a matter of adding that many seconds (or milliseconds) to the epoch and letting a date library work out the calendar date, time of day, and day of week for a given time zone. In JavaScript this is new Date(timestamp * 1000) for a seconds-based value, or new Date(timestamp) if it is already in milliseconds - which is exactly why getting the unit right matters before you trust the output.

Going the other direction - date to timestamp - just runs the same logic in reverse: parse the calendar date and time in a given zone, resolve it to an absolute instant, then express that instant as an integer count of seconds or milliseconds since the epoch. Once you have that instant, deriving an ISO 8601 string, a UTC representation, a local representation, or a relative '3 hours ago' label is just formatting the same underlying value in different ways.

1700000000

UTC: Tue, 14 Nov 2023 22:13:20
Local: depends on your time zone
ISO 8601: 2023-11-14T22:13:20Z
Relative: in the past (exact value depends on today's date)

1. Open the Unix Timestamp Converter and paste your epoch value, or pick a calendar date and time if you are going the other way.
2. Let the tool auto-detect whether your number is in seconds or milliseconds - override it manually if your value is ambiguous or unusually formatted.
3. Read the result across all the representations you need: UTC, your local time, the ISO 8601 string, and a human-friendly relative time like '2 days ago'.
4. Copy whichever representation your code, ticket, or query needs - the raw timestamp, the ISO string, or the formatted date.

Need the current epoch time right now? The tool keeps a live clock running so you can grab the current timestamp with one click, without doing the math yourself.

• Turning epoch values in logs, JSON payloads, and database exports back into readable dates.
• Reading JWT exp, iat, and nbf claims to see exactly when a token was issued or will expire.
• Building date-range filters for API requests or SQL queries that expect a Unix timestamp.
• Comparing UTC and local output to track down a time zone bug in a scheduling or reporting feature.
• Grabbing the current Unix time as a seed value for tests, fixtures, or a quick sanity check.

Mixing up seconds and milliseconds

This is the single most common timestamp bug. A recent date in seconds is a 10-digit number; the same instant in milliseconds is 13 digits. Feed a millisecond value into code that expects seconds and you land on a date sometime around the year 1970 plus a few weeks; feed a seconds value into code expecting milliseconds and you get a date centuries in the future. Always check the digit count, or let a converter detect the unit for you.

Assuming a timestamp implies a time zone

A raw timestamp has no time zone attached - it is the same instant everywhere. Bugs creep in when a UTC timestamp gets displayed or logged as if it were already local time, shifting the apparent date and hour. Always be explicit about which zone you are rendering in, and keep UTC as the value you store and pass between systems.

Forgetting timestamps can be negative

Dates before January 1, 1970 are represented as negative numbers, and not every hand-rolled parser handles that correctly. If you are working with historical records - archival data, old birth dates, legacy migrations - test that your conversion logic accepts negative values instead of assuming every timestamp is positive.

The 32-bit rollover (Year 2038 problem)

Older systems that store timestamps as a signed 32-bit integer will overflow on January 19, 2038, wrapping around to a negative value. Modern JavaScript, and most current databases and languages, use 64-bit representations that will not hit this limit for billions of years - but it is worth knowing about if you touch legacy C code, embedded systems, or very old database schemas.

• Store and pass timestamps in UTC; convert to a local time zone only at the moment you display them to a person.
• Prefer ISO 8601 strings for logs and APIs meant to be human-readable, and raw epoch numbers where compact, comparable values matter more.
• Document whether an API field is in seconds or milliseconds - do not make callers guess from the digit count.
• When debugging a token or session issue, decode the timestamp claims with a JWT decoder and cross-check them against the current time rather than assuming they are still valid.
• Pair timestamp fields with a stable identifier, such as one from a UUID generator, so records stay uniquely addressable even if two events share the same second.