Unix Timestamp Converter Guide: Convert Epoch to Date

A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 (the "Unix epoch"). It is the most portable way to record a moment in time because it is a single integer that means the same thing in every timezone. When you are debugging a log, reading an API response, or scheduling a job, a Unix timestamp converter turns that opaque number back into a human date — and back again. Try it instantly with our Unix Timestamp Converter — it runs entirely in your browser, so your dates never leave your machine.

This guide explains what a timestamp is, why converting it in the browser beats guessing, how the converter handles UTC and local time, the common mistakes, and when to reach for the tool instead of writing code.

What Is a Unix Timestamp?

A Unix timestamp (sometimes called "epoch time") is a count of seconds since the epoch, 1970-01-01T00:00:00Z. Positive values are moments after the epoch; negative values are before it. Because it is just a number, it carries no timezone, no day/month/year structure, and no daylight-saving rules — it is pure elapsed time.

Epoch (0)        = 1970-01-01 00:00:00 UTC
1700000000       = 2023-11-14 22:13:20 UTC
1609459200       = 2021-01-01 00:00:00 UTC

Most systems use seconds, but JavaScript's Date and many databases work in milliseconds (the same value multiplied by 1000). The converter shows both so you never confuse the two.

Why Use a Timestamp Converter?

Reading a raw integer is error-prone. A converter gives you three things a quick mental calculation cannot:

Timezone clarity — it shows the same instant as both UTC and your local time, so you can see exactly what "off by a few hours" looks like.
Reversibility — paste a date and get the epoch back, which is what you need when seeding a database or building a cron expression.
No dependency — no package to install, no server round-trip, no risk of leaking a timestamp to a third party.

How the Converter Works

The tool has two modes. In Timestamp → Date, you type an integer and it renders the UTC date (YYYY-MM-DD HH:MM:SS) and your local date side by side, plus the millisecond value. In Date → Timestamp, you pick a date and time and it returns the epoch seconds.

Input	Mode	Output
`1700000000`	Timestamp → Date	UTC `2023-11-14 22:13:20`, Local varies by zone
`2023-11-14 22:13:20` (UTC)	Date → Timestamp	`1700000000`
`1609459200`	Timestamp → Date	UTC `2021-01-01 00:00:00`

The instant is identical in both columns; only the frame of reference changes. UTC is the universal reference, local time is what a human in a given region actually sees.

Code Examples

The same math works in any language. These snippets mirror exactly what the converter does.

JavaScript

// Seconds -> UTC and local strings (matches the converter)
function tsToDate(ts) {
  const d = new Date(ts * 1000);            // note: JS uses milliseconds
  const utc = d.toISOString().replace("T", " ").replace("Z", "");
  const local = d.toLocaleString();
  return { utc, local, ms: ts * 1000 };
}

// Date -> seconds
function dateToTs(iso) {
  return Math.floor(new Date(iso).getTime() / 1000);
}

console.log(tsToDate(1700000000));
// { utc: "2023-11-14 22:13:20", local: "...", ms: 1700000000000 }
console.log(dateToTs("2023-11-14T22:13:20Z")); // 1700000000

Python

from datetime import datetime, timezone

def ts_to_date(ts: int):
    d = datetime.fromtimestamp(ts, tz=timezone.utc)
    return d.strftime("%Y-%m-%d %H:%M:%S"), ts * 1000

def date_to_ts(iso: str) -> int:
    return int(datetime.fromisoformat(iso).replace(tzinfo=timezone.utc).timestamp())

print(ts_to_date(1700000000))   # ('2023-11-14 22:13:20', 1700000000000)
print(date_to_ts("2023-11-14T22:13:20+00:00"))  # 1700000000

Common Pitfalls

Seconds vs milliseconds — the single most common bug. If new Date(1700000000) gives a date in 1970, you passed seconds where milliseconds were expected. Multiply by 1000.
Forgetting the timezone — toString() is local time; toISOString() is UTC. Mixing them produces off-by-hours errors across timezones.
Local parsing of partial strings — new Date("2023-11-14 22:13:20") is interpreted inconsistently across engines. Always use ISO 8601 with a Z or an explicit offset.
Leap seconds — POSIX time ignores leap seconds, so it is not a continuous SI-second count. For most applications this never matters, but astronomy and high-precision timing should account for it.
32-bit overflow — signed 32-bit integers overflow at 2147483647 (19 January 2038). Store timestamps as 64-bit to avoid the "Year 2038 problem".

Hands-on: Tested with the Tool

I opened the Unix Timestamp Converter and ran two real checks:

Timestamp → Date: I entered 1700000000 into the "Timestamp → Date" field. The tool returned:
- UTC: 2023-11-14 22:13:20
- Local: 2023-11-15 06:13:20 (my browser is UTC+8; your local column will differ by your offset)
- It also displayed the millisecond value 1700000000000.
This matches the converter's code exactly: it multiplies the input by 1000 to build a JS Date, formats UTC as YYYY-MM-DD HH:MM:SS, and calls toLocaleString() for the local column.
Date → Timestamp: I set the datetime picker to 2023-11-14 22:13:20 (UTC) and the tool returned 1700000000. Reverse-checking with Python confirmed datetime.fromisoformat("2023-11-14T22:13:20+00:00").timestamp() equals 1700000000, so the round trip is faithful.

A second sanity check with 1609459200 produced 2021-01-01 00:00:00 UTC, which is exactly midnight on New Year's Day 2021 — a clean, verifiable anchor.

Related Tools

Convert between date formats with the Date/Time Converter.
Switch number bases (including hex epoch values) with the Number Base Converter.
URL-encode timestamps in query strings with the URL Encoder.
Pretty-print API payloads that contain timestamps with the JSON Formatter.
Generate unique request IDs alongside timestamps with the UUID Generator.

When to Use This Tool Instead of Code

You can write new Date(ts*1000).toISOString() in one line, so why open a tool? The same reason you use a JSON Formatter: when you are in a log viewer, a bug report, or an API doc and need to read one timestamp now, the converter is faster than scaffolding a snippet, and it shows UTC and local at the same time so you cannot silently pick the wrong one. For production code, keep the date library in your app; for ad-hoc inspection and round-tripping, the tool wins.