Introduction / overview

Unix Time Converter takes one instant — whether you write it as a Unix timestamp, a UTC date and time, or a local time in one of 43 time zones — and shows that same instant everywhere else. Type a timestamp and read the human date in UTC, New York, London, Tokyo, or any of the other listed zones; or type a date and let the tool turn it back into a Unix timestamp.

Every box is editable and every box is the same instant. Edit the Unix time, the UTC/GMT date-time, or any single time zone, and all the others re-calculate automatically. You never have to type the same value twice or work out the offset yourself.

This is the tool to reach for when you are reading an API log that prints epoch seconds, checking when an email or file was actually created, converting a UTC timestamp you got from a database into your own time zone, or just comparing what time it is in several places for the same moment. Because the internal value is a plain number of milliseconds, the conversions are exact — there is no rounding to worry about.

How to use / quick start

1

Decide what your input really is

Is your timestamp in seconds, milliseconds, microseconds, or nanoseconds? Pick the matching unit next to Unix time — seconds is the default, but many databases and APIs hand out milliseconds.

2

Type into whichever box you have

Put the value you actually know into that field — a Unix time, a UTC/GMT date-time, or the local time in any listed time zone. Everything else fills in by itself.

3

Read the answer in the box you need

The time-zone groups (Eastern, Western, and their summer-time variants) show the same instant converted to each zone, including the ones that roll over to the previous or next day. The UTC/GMT box is the reference everything is measured from.

Example 1 — a Unix timestamp in seconds

Type $1735117200$ in Unix time with the unit set to seconds. The calculator multiplies by $1000$ to get the internal milliseconds, then converts that to the UTC calendar date:

1735117200\ \mathrm{s}

\times 1000

=

1\,735\,117\,200\,000\ \mathrm{ms}

\ \Rightarrow\

\text{12/25/2024 09:00:00 UTC}

The same instant in a few of the listed zones reads 12/25/2024 14:30:00 for IST (UTC+5:30), 12/25/2024 01:00:00 for PST (UTC−8), and 12/25/2024 22:00:00 for NZDT (UTC+13).

Example 2 — a date turned back into a timestamp

Type 01/19/2038 03:14:07 in the UTC/GMT box. The reverse conversion gives the Unix time in seconds:

\text{01/19/2038 03:14:07 UTC}

\ \mapsto\

2\,147\,483\,647\ \mathrm{s}

That number is not random — it is exactly $2^{31}-1$ , the largest value a 32-bit signed counter can hold. More on why that matters below.

Calculation method

Every field in the calculator is the same point in time, stored as a number of milliseconds since the Unix epoch ( $\text{01/01/1970 00:00:00 UTC}$ ). A time-zone field is simply that number plus the zone's fixed offset, and the date-time you see is the UTC calendar representation of that millisecond value.

From a time unit to milliseconds

t_{\mathrm{ms}}

=

t_{\mathrm{unit}}

\times

f_{\mathrm{unit}}

where $f_{\mathrm{unit}}$ is how many milliseconds one unit is worth:

Unit	Short	Milliseconds per unit
second	sec	1,000
millisecond	ms	1
microsecond	µs	0.001
nanosecond	ns	0.000001

From UTC to any time zone

TZ_{\mathrm{ms}}

=

UTC_{\mathrm{ms}}

+

\Delta_{\mathrm{TZ}}

\times

3\,600\,000

where $\Delta_{\mathrm{TZ}}$ is the zone's offset in hours from UTC. For example, IST sits at $+5.5\ \mathrm{h}$ , so $12/25/2024 09:00:00$ UTC shows as $12/25/2024 14:30:00$ in IST.

Which directions can it solve?

Unix time → UTC and every time zone (the usual direction)
UTC/GMT date-time → Unix time and every time zone
Any single time zone → UTC, Unix time, and all the other zones

Because the offsets are fixed per row, editing one zone never conflicts with the others — the same instant simply re-derives everywhere.

Unix time, the 2038 problem, and leap seconds

Unix time is simply a counter: the number of seconds elapsed since $\text{01/01/1970 00:00:00 UTC}$ . The date January 1, 1970 is called the epoch, and the counter can be negative for instants before it — which is why $0$ reads as 01/01/1970 00:00:00 and negative timestamps land in 1969 or earlier.

The 2038 problem

Systems that store the epoch in a 32-bit signed integer can only count up to $2\,147\,483\,647$ seconds — exactly $\text{01/19/2038 03:14:07 UTC}$ . One more second overflows the counter, and the value wraps around to a negative number, so the machine suddenly thinks the date is 1901. It is the same overflow idea as the older “Year 2000” bug, applied to a 32-bit seconds counter. Systems that moved to a 64-bit counter will not hit this for billions of years. If you want to see how that boundary looks as a raw bit pattern, the Binary Converter can show $2\,147\,483\,647$ in its 32-bit representation.

Leap seconds are ignored

Unix time counts whole seconds from the epoch and does not include leap seconds — the occasional extra second that UTC inserts to stay in step with the Earth's rotation. So the timestamp does not perfectly match physical time at the sub-second level of leap-second history, and this calculator follows the same convention. For almost all purposes — logs, databases, APIs, scheduling — that is exactly the behavior you want.

UTC vs GMT

GMT is the older name for the time at the prime meridian; UTC is the modern atomic-clock-based standard that replaced it. For converting a timestamp to a calendar date they are interchangeable, which is why the reference box is labelled UTC/GMT.

Frequently asked questions

Why is my timestamp off by a factor of 1,000?

Most likely it is a units mismatch. Many databases and APIs emit timestamps in milliseconds (e.g. $1735117200000$ ), while Unix time classically counts seconds ( $1735117200$ ). The calculator defaults to seconds, so switch the Unix time unit to milliseconds (or microseconds/nanoseconds) to match your source value.

Does this calculator apply daylight saving time?

No — and that is by design. Each row uses a fixed offset, so the standard zones and their summer-time variants are listed as separate rows (for example CET vs CEST). Pick the row that matches the rule in effect on the date you care about; the tool does not guess which one applies.

What is the maximum Unix timestamp?

For classic 32-bit storage it is $2\,147\,483\,647$ seconds, i.e. $\text{01/19/2038 03:14:07 UTC}$ . This calculator itself works with a far larger internal range of about $\pm 999\,999\,999\,999\,999\ \mathrm{ms}$ (roughly $\pm 31\,688$ years), so you can explore timestamps far beyond the 2038 boundary — the only limit is that no calendar date exists beyond that range.

Why does a negative timestamp show 1969 or 1970 dates?

Instants before the epoch are negative numbers. The reference $0$ is $\text{01/01/1970 00:00:00 UTC}$ , so a small negative value lands late in 1969. That is normal Unix time behavior, not a rounding error.

Limitations

Time-zone offsets here are fixed values, so the tool does not decide which daylight-saving rule is active for a given date — choose the standard or summer-time row yourself. Calendar dates are available within about $\pm 31\,688$ years of the epoch; further out there is no proleptic calendar date, and the calculator says so instead of guessing. Watch the Unix time unit, since seconds, milliseconds, microseconds, and nanoseconds differ by factors of 1,000. Finally, like Unix time itself, the conversion ignores leap seconds. For everyday timestamp work none of these are obstacles, but they are worth knowing when you compare against external sources.

Unix Time Converter

Introduction / overview

How to use / quick start

Calculation method

Frequently asked questions

Why is my timestamp off by a factor of 1,000?

Does this calculator apply daylight saving time?

What is the maximum Unix timestamp?

Why does a negative timestamp show 1969 or 1970 dates?

Limitations

Related Calculators

Scale Calculator

Roman Numeral Converter

Fraction to Percent Calculator

Grams to Tablespoons Converter

Decimal to Percent Converter

Salary to Hourly Calculator