Timestamp Converter

About the Timestamp Converter

This Unix timestamp converter turns an epoch value into a readable date, and a readable date back into an epoch value, in both directions from a single input field. Paste a number and it shows the equivalent in seconds, milliseconds, ISO 8601, UTC string, your local time and the weekday. Paste a date instead, in almost any common format, and it converts the other way. Leave the field empty and it fills in the current time.

Unix time (also called epoch time or POSIX time) counts seconds since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. It is how nearly every operating system, database and API stores a point in time internally, because a single integer is unambiguous, sorts numerically and needs no timezone metadata attached to it. The catch is that almost nobody reads epoch integers directly, so translating one to a date, or a date back to one, is a constant small chore for anyone touching logs, database rows, JWT claims or API payloads.

What sets this converter apart from a plain lookup is that it does the format detection for you. Values of up to eleven digits are read as seconds, twelve to fourteen digits as milliseconds, so you do not have to count digits or guess a divisor before pasting a value in. It does not auto-scale microsecond- or nanosecond-precision integers (16 or 19 digits); divide those down to a 13-digit millisecond value first. The reverse direction accepts ISO 8601 strings, RFC 2822/UTC strings and plain date strings like 2026-06-27, and normalises all of them to the same set of outputs.

Everything runs client-side in your browser using the native JavaScript Date object. No timestamp, date string or IP address is sent to a server or logged anywhere, which matters if you are pasting a value out of a production log or a customer record and would rather not forward it to a third party just to read the date.

How to use it

1. Paste a Unix timestamp in seconds (10 digits) or milliseconds (13 digits) into the input.
2. Or paste a date string instead, such as 2026-06-27 or an ISO 8601 timestamp, to convert the other way.
3. Leave the input empty and click 'use now' to fill in the current epoch time.
4. Read the unix (s) and unix (ms) rows to get both scales at once.
5. Read the ISO 8601 row when you need a value for an API request body or a log filter.
6. Compare the UTC row against the local row to see the offset your device is applying.
7. Check the weekday row when you only need to know what day a raw timestamp falls on.

Examples

• Paste 1700000000 to see it resolve to 2023-11-14T22:13:20.000Z (UTC).
• Paste 1700000000000 (13 digits) and it is read as milliseconds, same instant.
• Paste 2026-06-27 to get its Unix timestamp in both seconds and milliseconds.
• Paste 2026-01-19T03:14:08Z and compare it against the 2038-01-19 03:14:07 UTC rollover point.
• Leave the field blank and click 'use now' to grab the current epoch for a script or curl command.
• Paste a MySQL UNIX_TIMESTAMP() output like 1719480000 straight from a query result to check the date.

Seconds vs milliseconds: reading the digit count

The single biggest source of a wrong conversion is treating a millisecond value as seconds, which lands the result somewhere around the year 1970 plus a few minutes, or treating a seconds value as milliseconds, which lands it decades before 1970. The fix is to count digits before you divide anything: for dates from roughly 2001 to 2286, the digit count tells you the unit directly.

This converter detects seconds versus milliseconds automatically from the input length, using twelve digits as the cutover point, so you do not have to do this by hand for the common case. It does not accept microsecond- or nanosecond-scale integers directly, those need to be scaled down to milliseconds (or converted elsewhere) before pasting them in here.

• 10 or 11 digits, e.g. 1700000000: read as seconds since epoch (the most common Unix timestamp format)
• 12 to 14 digits, e.g. 1700000000000: read as milliseconds since epoch (JavaScript, Java, most JSON APIs)
• 16 digits (microseconds, e.g. a scaled-down Python time.time_ns()) or 19 digits (nanoseconds, e.g. Go's time.UnixNano()) are not recognised directly by this tool; divide by 1,000 or 1,000,000 first to get a 13-digit millisecond value
• Fewer than 10 digits: almost always seconds from before September 2001, or a malformed value
• A negative number is not read as a raw epoch value here; paste an equivalent date string instead, such as 1965-01-01, to get a pre-1970 result

The 2038 problem

Unix time was traditionally stored as a signed 32-bit integer, which can only count seconds up to 2,147,483,647. That value is reached at 03:14:07 UTC on 19 January 2038, one second after which a system still using a 32-bit signed timestamp wraps around to a large negative number and reads as a date in December 1901. This is the practical equivalent of the Y2K bug for anything still storing time in a 32-bit field.

Most current systems have already moved to 64-bit time_t (which pushes the limit out to roughly the year 292 billion) or store milliseconds in a 64-bit integer from the start, so the 2038 rollover mostly threatens older embedded systems, some 32-bit databases and legacy file formats that were never migrated. If you are testing date-handling code for that edge, a value just above 2147483647 is the one to throw at it.

• 2147483647 = 2038-01-19T03:14:07Z, the last second a signed 32-bit timestamp can represent
• 2147483648 = 2038-01-19T03:14:08Z, one second past the limit, wraps to 1901 on unpatched 32-bit systems
• 64-bit time_t or millisecond-based storage is unaffected and is now the default on modern platforms

Timezone pitfalls: epoch time is always UTC

A Unix timestamp has no timezone attached to it. It is a count of seconds from a fixed instant, so 1700000000 refers to exactly the same moment everywhere on Earth. The timezone only enters the picture when that instant gets rendered as a calendar date and clock time for a human to read, at which point a UTC offset has to be applied on top of the raw number.

The most common mistake is comparing a timestamp against a local-looking date string without checking which timezone that string was written in, or assuming a server-generated timestamp already reflects a user's local time when it never did. This converter shows both the UTC row and a local row rendered in your device's own timezone side by side, precisely so the two never get confused with each other.

• The raw integer never changes with timezone, only its rendered display does
• A date string without an explicit offset (e.g. 2026-06-27 12:00) is ambiguous, always check whether it was meant as UTC or local before converting
• Daylight saving changes affect the local rendering only, never the underlying epoch value
• For storage and APIs, keep values in UTC or as a raw epoch integer and only convert to local time at the point of display

How languages and databases expose the current timestamp

The unit and precision differ by platform, which is the other common source of an off-by-a-thousand or off-by-a-million error when passing a timestamp between a database, a backend and a frontend.

• JavaScript: Date.now() and new Date().getTime() return milliseconds since epoch
• Python: time.time() returns a float of seconds (fractional part is sub-second precision)
• MySQL / MariaDB: UNIX_TIMESTAMP() returns seconds; NOW() returns a DATETIME, not an epoch integer
• PostgreSQL: EXTRACT(EPOCH FROM now()) returns seconds as a double, including fractional seconds
• Java: System.currentTimeMillis() returns milliseconds; Instant.now().getEpochSecond() returns seconds
• Go: time.Now().Unix() returns seconds; time.Now().UnixNano() returns nanoseconds
• PHP: time() returns seconds; microtime(true) returns a float of seconds
• Redis: TTL and expiry commands operate in seconds unless the PX/EXAT-style variants are used, which are milliseconds

Frequently asked questions