Date & Time / Date & Time Tools

Unix Timestamp Converter

A Unix timestamp — also called epoch time, POSIX time or Unix time — is the number of seconds that have elapsed since 1970-01-01T00:00:00Z, the Unix epoch, with leap seconds ignored. This converter reads a value in seconds, milliseconds, microseconds or nanoseconds, reports which unit it recognised, and prints the same instant as ISO 8601, RFC 2822 and as a wall-clock reading in every time zone you add, from UTC to any IANA zone. It runs in both directions at once: type a timestamp and the calendar date appears, or type a date and time and the epoch value appears, with the two fields staying in step as you edit either one. Because the unit is inferred from magnitude, the digits 1758105331 are read as seconds — 2025-09-17 — while the thirteen-digit 1758105331123 is read as milliseconds, which is the same instant including milliseconds. Every offset is computed with your browser's own time zone database at the instant you are converting, so a zone that observes daylight saving shows its summer and winter readings correctly, and half-hour and 45-minute offsets such as +05:30 and +05:45 are handled natively. Nothing is uploaded and no request is made while you type: the whole conversion is arithmetic on numbers already in the page.

Current Unix timestamp

—

Seconds

—

Milliseconds

—

Unix timestamp

Date and time

Interpreted in time zone

Local time zone

Accepted format: YYYY-MM-DD HH:mm:ss, with optional .SSS and an optional Z or +08:00 suffix. No suffix means the wall clock above.

How to use

1
Read the live clock, or load it into the converter
The strip at the top shows the current Unix timestamp in seconds and in milliseconds, updating continuously. Copy either figure, or press Now to drop the current instant into the two fields below and work from there.
2
Enter a Unix timestamp on the left
Type or paste digits into the Unix timestamp field. Auto reads the unit from the magnitude of the number — ten digits or fewer as seconds, thirteen as milliseconds, sixteen as microseconds, nineteen as nanoseconds — and a badge names what it recognised. Press Seconds or Milliseconds to force a unit when you need to overrule it.
3
Or enter a date and time on the right
Type a date in YYYY-MM-DD HH:mm:ss form and the timestamp appears on the left. That entry is a wall clock, so choose the time zone it belongs to in the selector underneath; alternatively append Z or an offset such as +08:00 to the value itself, and it is read as an absolute instant with the zone selector ignored.
4
Add every time zone you need to compare
Each row of the table reports the same instant in one zone: its date, weekday, clock time, UTC offset and abbreviation. Weekdays and dates are evaluated in that zone rather than converted from yours, and offsets are computed at the instant being converted, so a zone with daylight saving shows the right offset for that date.
5
Copy the format the receiving system expects
Copy plain epoch seconds for a database, milliseconds for JavaScript, or a ready-made ISO 8601 or RFC 2822 string for an API payload, a log entry or an email header. The panel at the bottom tells you whether the instant still fits inside a signed 32-bit second counter.

Key facts

EpochUnix time counts the seconds elapsed since 1970-01-01T00:00:00Z, treating every day as exactly 86,400 seconds and ignoring leap seconds.Source:POSIX.1 (IEEE Std 1003.1)
2038 overflowA signed 32-bit second counter reaches its maximum, 2,147,483,647, at 2038-01-19T03:14:07Z and wraps on the next second — the Year 2038 problem.Source:POSIX.1-2017
Interchange formatRFC 3339 profiles ISO 8601 for internet timestamps, such as 2026-09-17T20:35:31+08:00, where the trailing Z means UTC.Source:RFC 3339
Date rangeECMAScript stores dates as milliseconds since the epoch and can represent ±8,640,000,000,000,000 ms, roughly 100,000,000 days either side of 1970.Source:ECMA-262
Leap secondsUTC has gained 27 leap seconds since 1972, none of which appear in Unix time — the two scales disagree by that accumulated amount.Source:IERS Bulletin C

Frequently asked questions

Why does Unix time start on 1 January 1970?

Unix was being written at Bell Labs in 1969 by Ken Thompson and Dennis Ritchie, and its time counter needed a starting point — an arbitrary but agreed moment that a simple integer could measure forward from. 1970-01-01 was a round date, close to the date of the work, and a 32-bit signed counter counting seconds from it reaches far enough into the future to be useful for decades, which is exactly the trade-off that later produced the 2038 problem. The convention was not instant: the first edition of the Unix Programmer's Manual described time as the number of sixtieths of a second since 1971-01-01, and the epoch was moved back to 1970-01-01 as the system matured. The value is not a claim about the calendar, only a reference point, which is why Unix time is defined at UTC rather than in any local time zone, and why the same number denotes the same instant everywhere. Negative timestamps simply count backwards from that point, so dates before 1970 are represented by negative numbers.

How do I tell whether a timestamp is in seconds or milliseconds?

Count the digits, because the magnitudes cannot overlap. Ten digits is seconds (1767225600 is 2026), thirteen is milliseconds, sixteen is microseconds and nineteen is nanoseconds. The underlying reason is that 100,000,000,000 seconds is already the year 5138, while 100,000,000,000 milliseconds is only 1973 — so any value at or above that boundary cannot be a second count. This tool applies that rule automatically and labels what it found, which matters because the same digits mean completely different instants: 1758105331 is 2025-09-17, whereas 1758105331 read as milliseconds is 1970-01-21. The one case where magnitude tells you nothing is zero, and a handful of values near the boundaries are ambiguous in principle, so the unit can be forced with the Seconds and Milliseconds buttons. A reliable tell in code: JavaScript's Date.now() returns milliseconds, while PHP's time() and Python's time.time() return seconds.

What is the 2038 problem?

On 2038-01-19 at 03:14:07 UTC, a Unix timestamp stored in a signed 32-bit integer reaches its largest value, 2,147,483,647 seconds. One second later it wraps to a large negative number, and software that has not been rebuilt interprets that as a date in December 1901 — the same class of failure as Y2K, but caused by integer width rather than by a two-digit year convention. The affected systems are the ones that still store time_t or an equivalent 32-bit column: older embedded devices, some file formats, 32-bit database columns and long-lived binaries. The fix is the same in each case — widen the field to 64 bits, which moves the limit roughly 292 billion years out — and most 64-bit operating systems and languages have already done it by default. The practical risk sits in data at rest rather than in computation: values written into 32-bit columns, files or protocols years ago and never migrated. This converter flags any instant outside the signed 32-bit range so you can see where that boundary actually falls.

Does Unix time count leap seconds?

No. UTC is an atomic clock time scale that keeps itself aligned with the Earth's rotation by inserting leap seconds — 27 of them have been added since 1972 — but POSIX time defines a day as exactly 86,400 seconds and ignores them entirely. So converting a timestamp to a UTC calendar date is exact, while the answer to how many physical seconds have elapsed since the epoch is not: the two differ by the accumulated leap seconds. The practical consequences are narrow but real. Unix time is not strictly monotonic with respect to UTC, and at the moment a leap second is inserted a Unix clock either repeats a second or briefly disagrees with UTC. Code that adds 86,400 seconds hoping to land on the same clock time tomorrow will be off by whatever the current offset is, which is why adding days is best done through a calendar library rather than by multiplying seconds.

How do I convert this timestamp in code?

In JavaScript, epoch seconds become a Date by multiplying: new Date(1758105331 * 1000), and going the other way is Math.floor(Date.now() / 1000) — note that Date.now() itself is already milliseconds, so it needs no multiplication. In Python, datetime.fromtimestamp(1758105331, tz=timezone.utc) gives an aware datetime, and datetime.timestamp() converts back; always pass the timezone, because the no-timezone form silently uses the machine's local zone. In SQL, PostgreSQL has to_timestamp(1758105331), MySQL has FROM_UNIXTIME(1758105331) paired with UNIX_TIMESTAMP(). Two mistakes account for most bugs here: feeding seconds into a milliseconds API or the other way round, and formatting a timestamp in the server's local zone when the stored value is UTC. Converting here first is a quick way to see what a value should look like before writing the query.

Related tools

Base64 in JSON

Encode and decode Base64 in the browser, including URL-safe Base64 and the payload section of a JWT. Runs locally; Base64 is encoding, not encryption.

JSON Formatter

Paste JSON to pretty-print it with consistent indentation, minify it to one line, or find the exact line and column of a syntax error. Runs locally.

JSON to TOML Converter

Convert JSON to TOML and TOML to JSON, with a clear choice for how null values are handled, since TOML has no null. Runs locally.