Unix Timestamp Converter
Convert Unix epochs to human dates and back.
100% in your browser — nothing uploadedConvert a Unix timestamp to a date
Example loaded: 1767225600 = January 1, 2026, 00:00 UTC
About this Unix timestamp converter
A Unix timestamp counts seconds since January 1, 1970 UTC — it’s how databases, logs, and APIs usually store time. Paste one and see the human-readable date in your local timezone, UTC, and ISO 8601. The tool auto-detects whether your value is in seconds or milliseconds.
It works in reverse too: pick a date and time, and get the epoch in seconds and milliseconds. A live clock shows the current timestamp, ready to copy. One thing about the reverse direction: the date field is read as local wall-clock time, so 09:00 entered in San Juan and 09:00 entered in Madrid produce different epochs. That is correct, and it is why the forward direction always shows UTC next to your local time.
The specification behind the number is unusually short. POSIX defines "seconds since the Epoch" with the rule that each and every day "shall be accounted for by exactly 86400 seconds", so Unix time deliberately ignores leap seconds. Twenty-seven have been inserted into UTC since 1972, the last on December 31, 2016, and none are in the count: an epoch value is a calendar calculation, not a tally of physical seconds elapsed. The 27th General Conference on Weights and Measures voted in 2022 to stop inserting them by 2035, which will freeze that gap at a fixed offset.
Which unit you get depends on the ecosystem, not on the standard. C’s time(), Python’s time.time(), Go’s Unix() and PostgreSQL’s to_timestamp() deal in seconds; JavaScript’s Date.now(), Java’s System.currentTimeMillis() and Kafka record timestamps deal in milliseconds; tracing formats often go to microseconds or nanoseconds. Digit count is the fastest tell: a present-day value is 10 digits in seconds, 13 in milliseconds, 16 in microseconds, 19 in nanoseconds. This tool reads anything at or above 1,000,000,000,000 as milliseconds — safe for any real date, but it means a microsecond value is misread and lands you in the year 57535, so divide by 1,000 first.
The year 2038 problem is the one hard deadline in the format. A signed 32-bit integer stops at 2,147,483,647, which as seconds since the epoch is 03:14:07 UTC on January 19, 2038; the next second wraps to December 1901. 64-bit time_t is standard on desktops and servers and the Linux kernel side of the 32-bit fix landed in 5.6, but plenty of application code still carries the bug, and long-dated arithmetic crossed the line years ago — a 30-year term signed in 2008 already matures past 2038. A smaller version is easy to hit today: through SQL Server 2022 the number argument to DATEADD is an int, so DATEADD(second, 1753488000, ...) works while DATEADD(millisecond, 1753488000000, ...) raises an arithmetic overflow.
Epoch is the wrong format for anything that is a calendar date rather than an instant. A birthday, a contract date, an all-day event: none has a single moment attached, and storing them as a DATE keeps them correct in every timezone. Future appointments in a named place are the other trap. Governments change their UTC offsets with a few months’ notice — Mexico dropped daylight saving across most of the country in 2022 — so an epoch computed today for a meeting next year quietly becomes the wrong wall-clock time if the rule changes first. Store local time plus the IANA zone identifier and resolve the instant when you need it.
Unix timestamp cheat sheet: SQL, code and the 2038 limit
Take 1753488000 as a worked example. That is Saturday, July 26, 2025 at 00:00:00 UTC — and the very same number is Friday, July 25 at 20:00 in San Juan, because Puerto Rico sits at UTC-4 all year. The number never changes; only the label you put on it does.
| Engine | Epoch seconds → date | Date → epoch seconds |
|---|---|---|
| PostgreSQL | to_timestamp(1753488000) | EXTRACT(EPOCH FROM now()) |
| MySQL | FROM_UNIXTIME(1753488000) | UNIX_TIMESTAMP('2025-07-26 00:00:00') |
| SQLite | datetime(1753488000, 'unixepoch') | unixepoch('2025-07-26') |
| SQL Server | DATEADD(second, 1753488000, '1970-01-01') | DATEDIFF(second, '1970-01-01', GETUTCDATE()) |
| Oracle | DATE '1970-01-01' + 1753488000/86400 | (ts - DATE '1970-01-01') * 86400 |
| BigQuery | TIMESTAMP_SECONDS(1753488000) | UNIX_SECONDS(CURRENT_TIMESTAMP()) |
| Snowflake | TO_TIMESTAMP(1753488000) | DATE_PART(EPOCH_SECOND, CURRENT_TIMESTAMP()) |
Those rows are not interchangeable. PostgreSQL’s to_timestamp returns a timestamp with time zone anchored to UTC, while MySQL documents that FROM_UNIXTIME returns the value "expressed using the session time zone" — the same input, two different printed strings, and a round trip through a non-UTC session is explicitly lossy across DST changes. Oracle has no epoch function at all, so you add days to a DATE literal, which is why the constant is divided by 86400. SQL Server’s DATEADD takes an int through SQL Server 2022 (bigint from SQL Server 2025 and on Azure SQL and Fabric), so the millisecond form overflows on older versions; convert to seconds first, or split the value with integer division.
| Digits | Unit | 2025-07-26 00:00:00 UTC looks like |
|---|---|---|
| 10 | seconds | 1753488000 |
| 13 | milliseconds | 1753488000000 |
| 16 | microseconds | 1753488000000000 |
| 19 | nanoseconds | 1753488000000000000 |
Everyone guesses the unit from magnitude, including database vendors: Snowflake documents that TO_TIMESTAMP treats an integer below 31,536,000,000 (the number of milliseconds in a year) as seconds, and larger values as milliseconds, microseconds or nanoseconds by the same escalating thresholds. This tool uses a simpler cut at 1,000,000,000,000. Both heuristics are safe for present-day dates and both break on synthetic values, so if you are converting a whole column, check the digit count once rather than trusting per-row detection.
date -u -d @1753488000 # GNU coreutils (Linux)
date -ur 1753488000 # BSD date (macOS)
python -c "import datetime as d; print(d.datetime.fromtimestamp(1753488000, d.timezone.utc))"
node -e "console.log(new Date(1753488000 * 1000).toISOString())"Finally, the ceiling. A signed 32-bit epoch runs out at 2147483647 = 2038-01-19 03:14:07 UTC. If you want to see what a system does past that boundary, paste 2147483648 above: this tool is 64-bit and will happily show you 2038-01-19 03:14:08, which is the answer a correct system should give.
Discord dynamic timestamps
Discord turns <t:UNIX:STYLE> into a timestamp shown in each reader's own time zone and language. You write it once and everyone sees their local time.
<t:1735689600:F>| Style | What it shows |
|---|---|
| t | Short time — 20:00 |
| T | Long time — 20:00:00 |
| d | Short date — 01/01/2026 |
| D | Long date — 1 January 2026 |
| f | Short date and time (used when you leave the style off) |
| F | Long date and time with the weekday |
| R | Relative — "in 2 hours", "3 days ago" |
Gotcha: the number is Unix seconds, not milliseconds. Paste a 13-digit millisecond value and Discord shows a year around 50000 — use the seconds value from the box above.
Reference tables
FAQ
Seconds or milliseconds — how do I tell?
10-digit values (like 1753488000) are seconds; 13-digit values are milliseconds. The tool detects this automatically.
What timezone is a Unix timestamp in?
None — it’s always UTC by definition. Timezones only matter when you display it, which is why we show both local and UTC.
What is the year 2038 problem?
Systems storing timestamps as signed 32-bit integers overflow on January 19, 2038. Modern 64-bit systems are unaffected.