Unix Timestamp Converter — Epoch to Date, UTC/EST/GMT, Discord & Hex

What a Unix timestamp actually is

A Unix timestamp (also called epoch time or POSIX time) is a single number: the count of seconds that have elapsed since 1970-01-01 00:00:00 UTC, a moment known as the epoch. Because it is one integer with no time zone, no daylight-saving rules, and no formatting, it is the simplest way for computers to store, compare, and sort moments in time — which is the whole purpose of a Unix timestamp converter: turning that opaque integer into a date you can actually read, and back again. 0 is the epoch itself; 1000000000 is 2001-09-09 01:46:40 UTC; 1700000000 lands in November 2023.

Convert a timestamp to a date — and back

Paste a number into the Timestamp → date field above and you get the same instant rendered several ways at once — UTC, your local zone, any zone you pick, ISO 8601, the RFC 2822 form used in HTTP and email headers, the ISO week and day-of-year, and a relative “x ago” phrase. Go the other way with Date → timestamp to turn a calendar date back into an epoch value. Have a whole column of timestamps from a log file? Switch to the Batch tab, paste one per line, and convert them all at once — each row is unit-detected on its own, and Copy all gives you tab-separated output ready to drop into a spreadsheet.

The seconds-vs-milliseconds trap

This is the single most common bug when working with timestamps. The original Unix contract is seconds, and that is what PostgreSQL’s EXTRACT(EPOCH ...), date +%s, Python’s time.time() (as an integer), and most APIs return. JavaScript breaks the pattern: Date.now() returns milliseconds.

Mixing the two is what produces dates in 1970 (you fed seconds to a millisecond parser) or far in the future (you fed milliseconds to a second parser). A fast sanity check: a current timestamp in seconds is 10 digits; in milliseconds it is 13 digits. The converter auto-detects this from the size of the number, but you can force the unit with the Seconds / Milliseconds toggle when you are dealing with historical or far-future dates where the digit count is ambiguous.

Converting between the two in code:

// JavaScript: ms ⇄ s
const seconds = Math.floor(Date.now() / 1000);
const date = new Date(seconds * 1000); // multiply back up to ms

# Python: seconds is the native unit
import time, datetime
ts = int(time.time())
datetime.datetime.fromtimestamp(ts, datetime.timezone.utc)

-- PostgreSQL: epoch seconds → timestamp
SELECT to_timestamp(1700000000);

UTC, EST, PST, GMT, and any time zone

A Unix timestamp does not carry a time zone — it is an absolute instant. Two servers in London and New York that record the same event store the identical number. The zone only enters when you turn that number into something a human reads, which is why the converter shows several zones side by side from a single value: UTC, your local zone, and a third zone of your choosing — pick America/New_York to convert a Unix timestamp to EST/EDT (UTC−5 in winter, UTC−4 in summer), America/Los_Angeles for PST/PDT, or Europe/London for GMT/BST. The picker lists every IANA zone, and each result shows the matching abbreviation (EST, PST, GMT…) automatically. When you store time, store the epoch (or a UTC timestamp); apply the user’s zone only at display time — storing local times is how off-by-an-hour daylight-saving bugs are born.

The Date → timestamp direction includes an Interpret as toggle for exactly this reason: the same wall-clock string (“2024-03-10 02:30”) is a different instant depending on whether you mean local time or UTC, so you get to say which.

Unix timestamps in Discord

Discord renders dates with a small markdown syntax: <t:UNIX:STYLE>, where UNIX is a Unix timestamp in seconds and STYLE is a single letter that controls how it’s displayed. Discord always evaluates the timestamp in each viewer’s own local time zone, so a scheduled-event message shows correctly for everyone regardless of where they are. The seven styles are:

• t — Short Time, e.g. 9:41 PM
• T — Long Time, e.g. 9:41:30 PM
• d — Short Date, e.g. 11/14/2023
• D — Long Date, e.g. November 14, 2023
• f — Short Date/Time, e.g. November 14, 2023 9:41 PM
• F — Long Date/Time, e.g. Tuesday, November 14, 2023 9:41 PM
• R — Relative, e.g. 3 hours ago / in 2 days

Paste your timestamp into the converter above and the Discord timestamp section generates all seven codes ready to copy straight into a message.

Converting Unix timestamps in Excel and Google Sheets

Spreadsheets store dates as days since 1899-12-30 (Excel) or 1899-12-30 in Sheets too, not seconds since 1970, so a Unix timestamp needs a small formula to become a real date cell — and back:

' Unix timestamp (seconds) → date, in cell A1:
=(A1/86400)+DATE(1970,1,1)

' Date in cell B1 → Unix timestamp (seconds):
=(B1-DATE(1970,1,1))*86400

Format the result cell as a date/time after using the first formula, or you’ll just see a serial number. Both formulas produce UTC-equivalent results — if your source timestamps represent local time, add or subtract the zone offset in hours before converting.

Hex Unix timestamps

Timestamps occasionally show up base-16 rather than base-10 — inside binary file headers, some blockchain and firmware formats, and debugger dumps of raw memory. A hex Unix timestamp is the same epoch value, just written in hexadecimal instead of decimal, often with a 0x prefix (e.g. 0x653a5c00 is 1698230784 in decimal). Switch the Base toggle above from Dec to Hex to paste a hex value directly — with or without its 0x prefix — and the Hex output field converts any decimal timestamp you enter the other way.

Common durations in Unix time

Because a Unix timestamp is just a count of seconds, durations are plain arithmetic — no calendar math, no time zone to account for:

• 1 minute = 60
• 10 minutes = 600
• 1 hour = 3,600
• 1 day = 86,400
• 1 week = 604,800
• 30 days = 2,592,000
• 1 year (365 days) ≈ 31,536,000

Adding one of these numbers to any timestamp moves it forward by exactly that duration, which is why epoch time is so common for token expiry, cache TTLs, and rate-limit windows.

The Year 2038 problem

If a timestamp is stored in a signed 32-bit integer, the largest value it can hold is reached at 2038-01-19 03:14:07 UTC, after which it overflows and wraps back to 1901. Modern languages and databases use 64-bit integers and are unaffected, but the issue still lurks in legacy C code and old embedded firmware. It is the main reason you should never assume a timestamp column is “big enough” without checking its type.

Related tools

Building a front end as well as a back end? Keep your spacing scale honest with the CSS px to rem converter, and make sure your UI passes contrast requirements with the color contrast checker. Shipping a site? The favicon checker verifies your <head> markup the same way this converter verifies a timestamp. A JWT decoder is on the way too — handy because a token’s exp and iat claims are Unix timestamps you will often want to convert by hand.