Where does "this device" come from?

The time zone the browser reports, which follows your computer or phone settings. The zone name (Asia/Tokyo and the like) and the offset are shown at the top so you can confirm it is the setting you expected. To compare against a server, use the UTC row — it does not depend on this device at all.

Does it handle daylight saving?

Yes. The offset is taken from the instant in question, so it switches by itself between summer and winter. Note that at a transition one hour either does not exist or happens twice; a time inside the missing hour is nudged to a nearby instant by the browser’s own rules, and a time inside the repeated hour is read as one of its two possible instants. Write the offset into the text (+09:00) or enter it as UTC when the difference matters.

Negative values and fractions?

Negative values are dates before 1970 and work normally. A fractional number of seconds (1786500000.5) is accepted and converted to milliseconds; the displayed clock time is whole seconds, so read the milliseconds row for anything finer. A number far outside the representable span is reported as out of range rather than printed as nonsense.

Which date formats are accepted?

2026-08-15, 2026-08-15 12:34:56, 2026/8/15 12:34, 2026-08-15T12:34:56Z and 2026-08-15T12:34:56+09:00. When the text carries a Z or an offset, that takes precedence over the zone switch. With the time omitted, midnight is assumed. A date that does not exist — 30 February — is rejected rather than rolled forward to 2 March, because saying the input is wrong is safer than silently changing it.

Is anything uploaded?

No. Every calculation happens in the page, so timestamps out of logs you cannot share are fine to paste here. The clock at the top comes from your own device, not from a time server.

The number of seconds since 1970-01-01 00:00:00 UTC. It carries no zone and no daylight saving, so the same number means the same instant everywhere. That is its strength, and also why it has to be converted before a person can read it. Storing timestamps this way lets them be shown later in any zone; storing a local-time string instead throws the offset away, and the original instant cannot be recovered.

Why milliseconds are so common

JavaScript’s Date.now() and Java’s System.currentTimeMillis() both return milliseconds, which is the same value times a thousand — three more digits. For any realistic date after 1970 that means ten digits for seconds and thirteen for milliseconds, which is what the automatic detection here looks at. Read milliseconds as seconds and you land fifty thousand years out; read seconds as milliseconds and you land just after 1970. When the answer looks absurd, suspect the unit first.

Systems that store the count in a signed 32-bit integer overflow at 2038-01-19 03:14:07 UTC and wrap round to 1901. Anything storing it in 64 bits is unaffected. This page computes in double-precision floating point, so it has no such ceiling. Systems that work with future dates — expiry dates, maturity dates — tend to hit the wall well before 2038 arrives.

Leap seconds are not counted

Unix time treats every day as exactly 86,400 seconds, so the leap seconds that were actually inserted are absent from it. The difference between two Unix times is therefore a few dozen seconds away from the true elapsed time. That is irrelevant for everyday use and disqualifying for astronomy or positioning, which use other scales. At the moment one is inserted, systems either repeat the same Unix time twice or slow the clock slightly to absorb it — and which of the two decides what a timestamp recorded in that second means.

Back to all tools／ Text & data

Unix time converter

Runs in your browserNothing is uploaded

Convert epoch seconds or milliseconds to a date and back. Local time and UTC are shown together, ISO 8601 is given both with an offset and in UTC, and the current Unix time is always on screen.

Input

Unix time right now

Seconds—

Milliseconds—

This device—

Direction

Unix time (a number)

Input unit

Auto reads the magnitude: 1e11 or above is milliseconds. Set the unit explicitly if that guess is not what you meant.

Result

Nothing here yet

Epoch seconds count from 1970-01-01 00:00:00 UTC and carry no offset. Your device time and UTC are shown side by side so the two are never mistaken for each other.

All tools

Highlights

Seconds and milliseconds are not confused: Logs usually hold seconds and JavaScript APIs hold milliseconds; mixing them lands you in 1970 or in the far future. The unit is inferred from the magnitude, the page states which reading it used, and you can set it explicitly. A guess made silently leaves nothing to check the answer against, which is why the reading is always written out.
Local and UTC, together: Nearly every timestamp discrepancy is one side in UTC and the other in local time. Both are shown at once with the offset spelled out, so which is which is never a guess. The device’s zone name sits at the top of the page too, so a machine set to the wrong zone gives itself away immediately.
ISO 8601 with a real offset: toISOString always reports UTC with a trailing Z. When what you need is the local time written as +09:00, that has to be built by hand — so both forms are given. Labelling a local time with a Z is the standard way to end up with records nine hours out.

How to use it

Choose a direction
Pick "Epoch → date" or "Date → epoch". The current Unix time sits at the top of the page in both seconds and milliseconds, ready to copy on its own.
Enter a value
Type the number or the date into the field. "Use the current time" fills in whichever the chosen direction needs. On the epoch side you can set the unit (auto, seconds, milliseconds); on the date side you can say whether the input is this device’s time or UTC.
Read the result
Local time, UTC, both ISO 8601 forms, epoch seconds and milliseconds, and the distance from now are listed together. The button beside a value copies that one line on its own.

Unix time, briefly

What it is: The number of seconds since 1970-01-01 00:00:00 UTC. It carries no zone and no daylight saving, so the same number means the same instant everywhere. That is its strength, and also why it has to be converted before a person can read it. Storing timestamps this way lets them be shown later in any zone; storing a local-time string instead throws the offset away, and the original instant cannot be recovered.
Why milliseconds are so common: JavaScript’s Date.now() and Java’s System.currentTimeMillis() both return milliseconds, which is the same value times a thousand — three more digits. For any realistic date after 1970 that means ten digits for seconds and thirteen for milliseconds, which is what the automatic detection here looks at. Read milliseconds as seconds and you land fifty thousand years out; read seconds as milliseconds and you land just after 1970. When the answer looks absurd, suspect the unit first.
The 2038 problem: Systems that store the count in a signed 32-bit integer overflow at 2038-01-19 03:14:07 UTC and wrap round to 1901. Anything storing it in 64 bits is unaffected. This page computes in double-precision floating point, so it has no such ceiling. Systems that work with future dates — expiry dates, maturity dates — tend to hit the wall well before 2038 arrives.
Leap seconds are not counted: Unix time treats every day as exactly 86,400 seconds, so the leap seconds that were actually inserted are absent from it. The difference between two Unix times is therefore a few dozen seconds away from the true elapsed time. That is irrelevant for everyday use and disqualifying for astronomy or positioning, which use other scales. At the moment one is inserted, systems either repeat the same Unix time twice or slow the clock slightly to absorb it — and which of the two decides what a timestamp recorded in that second means.

Questions

Where does "this device" come from?: The time zone the browser reports, which follows your computer or phone settings. The zone name (Asia/Tokyo and the like) and the offset are shown at the top so you can confirm it is the setting you expected. To compare against a server, use the UTC row — it does not depend on this device at all.
Does it handle daylight saving?: Yes. The offset is taken from the instant in question, so it switches by itself between summer and winter. Note that at a transition one hour either does not exist or happens twice; a time inside the missing hour is nudged to a nearby instant by the browser’s own rules, and a time inside the repeated hour is read as one of its two possible instants. Write the offset into the text (+09:00) or enter it as UTC when the difference matters.
Negative values and fractions?: Negative values are dates before 1970 and work normally. A fractional number of seconds (1786500000.5) is accepted and converted to milliseconds; the displayed clock time is whole seconds, so read the milliseconds row for anything finer. A number far outside the representable span is reported as out of range rather than printed as nonsense.
Which date formats are accepted?: 2026-08-15, 2026-08-15 12:34:56, 2026/8/15 12:34, 2026-08-15T12:34:56Z and 2026-08-15T12:34:56+09:00. When the text carries a Z or an offset, that takes precedence over the zone switch. With the time omitted, midnight is assumed. A date that does not exist — 30 February — is rejected rather than rolled forward to 2 March, because saying the input is wrong is safer than silently changing it.
Is anything uploaded?: No. Every calculation happens in the page, so timestamps out of logs you cannot share are fine to paste here. The clock at the top comes from your own device, not from a time server.

Input

Result

Related tools

Highlights

How to use it

Choose a direction

Enter a value

Read the result

Unix time, briefly

Questions