Unix Timestamp Converter

epoch seconds = days since 1970-01-01 × 86400 + seconds since midnight UTC; date and time = the same arithmetic run backwards

mode

Which direction to go: a timestamp entered and a date returned, or a date and time entered and a timestamp returned

timestamp

The count itself, in seconds or in milliseconds depending on the unit field. Only used in the timestamp-to-date direction

unit

Whether the number you entered counts seconds (10 digits for dates in this century) or milliseconds (13 digits). Only used in the timestamp-to-date direction

date

The calendar day at UTC, written as YYYY-MM-DD. Only used in the date-to-timestamp direction

time

The wall clock at UTC, as HH:MM or HH:MM:SS. Only used in the date-to-timestamp direction

utcDate

The calendar date the timestamp falls on, in UTC. This is the headline result

utcTime

The clock time in UTC, always with seconds. Any fraction of a second in the input is dropped rather than rounded

utcWeekday

The day of the week that date falls on, as a number from 0 (Sunday) to 6 (Saturday)

isoDateTime

The full ISO 8601 form, like 2026-01-15T12:00:00Z, ready to copy into code or a log

timestampSeconds

The same instant as whole seconds since 1970-01-01T00:00:00Z, truncated rather than rounded so it never disagrees with the clock time above it

timestampMilliseconds

The same instant in milliseconds — the seconds value times 1000, keeping any sub-second part the input carried

Use it when a number and a date have to be matched up: reading a timestamp out of a server log, an API response or a database row; checking whether a value you were sent is in seconds or milliseconds; or generating a timestamp to store. The page deliberately stops at UTC. It does not convert to your local time and does not ask which zone you are in — a Unix timestamp has no zone, so the honest answer is a UTC one, and turning that into a local clock reading is the time zone calculator's job. It also does not do arithmetic on timestamps: for "what is this plus thirty days", convert first and use a date calculator.

1. 1768478400 — the reference instant

   1. The number is in seconds, so it is already the epoch value — no conversion is needed before reading it
   2. Dividing by 86400 gives the number of whole days since 1 January 1970, and the remainder is the time of day: the result lands on 15 January 2026 at 12:00:00 UTC
   3. 15 January 2026 is a Thursday, so the weekday number is 4
   4. Written out in full it is 2026-01-15T12:00:00Z, the form a log or an API expects
   5. The milliseconds row is the same instant times 1000, which is what the same value looks like when a system reports it in milliseconds instead

   This is the value the page opens on, and it is worth memorising as an anchor: 1768478400 is noon UTC on 15 January 2026. Every other conversion on this page is easier to sanity-check once one timestamp is familiar, because a wrong answer is usually wrong by whole days or by a factor of 1000, and both show up immediately against an anchor you know.

2. 2147483647 — the last second of the 32-bit era

   1. 2147483647 is 2 to the power of 31 minus 1: the largest number a signed 32-bit integer can hold
   2. Read as an epoch count it is 19 January 2038 at 03:14:07 UTC, which is what the 2038 problem is about — systems storing timestamps in that type run out of room one second later and wrap to a date in 1901
   3. 19 January 2038 is a Tuesday, weekday 2
   4. The seconds row returns the number unchanged, which is the check that the value went in and came back out through the same arithmetic

   This is the row from the reference table below, run through the calculator. The 2038 problem is not that the date is unreachable — this page handles it without complaint — but that a program using a 32-bit signed counter cannot represent the next second. Sixty-four-bit counters have no such edge within any horizon that matters, which is why the same value in milliseconds is 2147483647000.

3. A millisecond value with a fraction: 1768478400500

   1. The number has 13 digits and the unit says milliseconds, so it is the same instant as the first example plus half a second
   2. The clock time drops the fraction rather than rounding it, so it reads 12:00:00 and not 12:00:01
   3. The seconds row is truncated to match: 1768478400, not 1768478401
   4. The milliseconds row keeps the fraction, because that is the one place it exists in the result

   The one case where rounding and truncating disagree, and the reason the seconds row truncates. Rounding half a second up would print a seconds value one greater than the clock time directly above it, and a reader comparing the two rows would conclude that one of them is broken. Keeping every row consistent with the displayed time matters more than keeping the nearest integer.

4. The other direction: 15 January 2026, 12:00:30 UTC

   1. The date is turned into a day count since 1 January 1970 and multiplied by 86400 to get the seconds up to midnight
   2. Thirty seconds past midnight is added: the total is 1768478430, which is the first example's value plus 30
   3. The time field accepts seconds, so 12:00:30 is read exactly rather than being rounded down to the minute
   4. The date and weekday rows come back unchanged, because converting out and in again is the identity operation

   Running the reverse direction on a value you already converted is the cheapest way to check a timestamp: if the round trip does not come back to the number you started with, the unit was probably wrong. Filling in a 10-digit number while the unit says milliseconds is off by a factor of a thousand, and it shows up here as a date in January 1970 rather than as an error.

Everything the page reports is in UTC, and it never converts to a local time zone — a Unix timestamp is defined without one, so the page that turns it into a local clock reading is the time zone calculator. The window is 1970-01-01T00:00:00Z through 2100-12-31T23:59:59Z, and values outside it are rejected rather than quietly computed: negative timestamps are legal Unix timestamps for dates before the epoch, but the page says so and stops instead of returning a 1969 answer that contradicts its own stated range. Fractions of a second are truncated, not rounded, so a millisecond value does not lose its precision but also does not influence the displayed seconds. The page does not parse date strings in other formats, does not read the timestamp of the machine you are on, and does not do arithmetic — for the date thirty days from a converted value, use a date calculator.

What is epoch time?

Epoch time is the number of seconds that have passed since 1970-01-01T00:00:00 UTC, which is the zero point Unix systems count from. It is also called Unix time or POSIX time. Nothing about it depends on where you are: epoch time is defined in UTC, so the same instant has the same value worldwide, and two machines in different zones that disagree about the local clock still agree about the timestamp.

How do I convert a timestamp to a date?

Enter the value, say whether it counts seconds or milliseconds, and read the date and time that come back. The one thing to check first is the number of digits: a count of seconds for a date in this century has 10 digits and a count of milliseconds has 13. A 13-digit value read as seconds lands tens of thousands of years in the future and is refused; a 10-digit value read as milliseconds lands in January 1970, which is the mistake that does not announce itself. Converting back with the other direction is the quickest confirmation.

What is the 2038 problem?

The 2038 problem is what happens when a system stores a timestamp in a signed 32-bit integer: the largest value that type holds is 2147483647, which is 2038-01-19T03:14:07 UTC, and one second later the counter overflows to a date in 1901. It is a storage limit rather than a limit of the timestamp itself, and 64-bit counters do not have it. This page converts that value and the ones beyond it without trouble, because it works in double precision rather than in 32-bit integers.

Should I store seconds or milliseconds?

Both are in wide use and neither is wrong, but a value on its own does not say which one it is, so the unit has to travel with the number or be agreed in advance. Milliseconds preserve fractions of a second and are what JavaScript's Date object and many logging systems use; seconds are what POSIX defines and what most APIs and databases return. Converting between the two is a multiplication by 1000, and this page prints both rows so the pair is visible at a glance.

Is the ISO 8601 format the same as a timestamp?

No, and they are easy to confuse because both describe the same instant. ISO 8601 is the written form — 2026-01-15T12:00:00Z — and it is human-readable, sortable and unambiguous about the UTC offset via the trailing Z. A Unix timestamp is a single count with no formatting at all. The ISO 8601 string is what you paste into a document or a URL; the count is what you store or compare. This page prints both from the same conversion, so the two can be checked against each other.

• The Open Group Base Specifications — Seconds Since the Epoch — The Open Group — the normative definition of the epoch and of leap-second handling
• RFC 3339 — Date and Time on the Internet: Timestamps — IETF — the format of the Z-suffixed string this page prints
• MDN — Date — MDN Web Docs — the millisecond count and its range in JavaScript