Developer Unix timestamp converter
Convert Unix timestamps to human dates and back, in seconds or milliseconds, with a live clock and a relative-time readout.
Current Unix time
1789067761
2026-09-10T19:16:01.125Z
Any format the browser understands, e.g. 2026-01-01 09:30
Unix seconds
1789067761Unix milliseconds
1789067761000ISO 8601 (UTC)
2026-09-10T19:16:01.000ZLocal time
9/10/2026, 7:16:01 PMUTC string
Thu, 10 Sep 2026 19:16:01 GMT- Relative
- just now
- Date only
- 2026-09-10
- Your offset
- UTC+00:00
Ready. Runs locally on your device.
Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.
Share result
Cite
Cite this page
Reembun. (2026, July 28). Unix timestamp converter. https://reembun.com/epoch-converter
How to use it
Set the unit
Timestamp unit tells the converter whether your number is in seconds or milliseconds, which is the difference between 2026 and 1970.
Paste the timestamp
Or work the other way and type a date into Or a date, in almost any format the browser understands.
Read every form
Local time, UTC, the ISO 8601 string, the date on its own and a relative phrase such as two hours ago are all shown for the same instant.
Grab the time now
Copy current timestamp gives you a value for right now, which is what you usually want when you are testing.
What a Unix timestamp is
The number of seconds elapsed since 00:00:00 UTC on 1 January 1970, called the Unix epoch. It is a single integer, always in UTC, carrying no time zone or locale.
That simplicity is the point. Storing time as an integer makes comparison, sorting and arithmetic trivial, and sidesteps every ambiguity of formatted dates: no parsing, no locale, no daylight saving.
Seconds or milliseconds
Both are in wide use, and telling them apart is the practical skill.
| Digits | Unit | Example | Represents |
|---|---|---|---|
| 10 | seconds | 1767225600 | 1 Jan 2026 |
| 13 | milliseconds | 1767225600000 | 1 Jan 2026 |
| 16 | microseconds | 1767225600000000 | Some databases |
| 19 | nanoseconds | 1767225600000000000 | Go, some tracing systems |
JavaScript uses milliseconds, so Date.now() returns 13 digits.
Unix tooling, PHP, Python’s time(), most SQL use seconds.
Passing one where the other is expected gives a date that is obviously wrong by a factor of a thousand, which is at least an easy bug to spot.
Reference timestamps
| Timestamp | Date |
|---|---|
| 0 | 1 Jan 1970, 00:00:00 UTC, the epoch |
| 1000000000 | 9 Sep 2001 |
| 1500000000 | 14 Jul 2017 |
| 1700000000 | 14 Nov 2023 |
| 2000000000 | 18 May 2033 |
| 2147483647 | 19 Jan 2038, 32-bit overflow |
The 2038 problem
A signed 32-bit integer maxes out at 2,147,483,647, which as a Unix timestamp is 03:14:07 UTC on 19 January 2038. One second later it wraps to negative, and the date becomes December 1901.
Most current systems store time in 64 bits and are unaffected. What remains at risk is embedded firmware, older file formats, and database columns typed as a 32-bit integer years ago and never revisited. Unlike Y2K, the fix is a data type change rather than a display change, which makes it harder to retrofit.
Negative timestamps
Dates before 1970 are negative. -86400 is 31 December 1969. Support varies: most modern languages handle negative timestamps correctly, but some libraries and many database drivers do not, which is worth knowing if you store historical dates as epochs.
Working with timestamps well
Store UTC, display local. Convert only at the presentation layer. Storing local time loses information that cannot be recovered once daylight saving has moved.
Be explicit about units. Name the field created_at_ms rather than created_at when it holds milliseconds. The type does not tell you, and the next person will guess wrong.
Do not use timestamps for future scheduled events. Time zone rules and daylight saving dates change by legislation. An event scheduled for “9am local next November” should be stored as a wall-clock time plus a zone identifier, not as an epoch, because the correct epoch may change before it arrives.
Common questions
Is my timestamp in seconds or milliseconds?
Count the digits. A current timestamp in seconds is 10 digits; in milliseconds it is 13. If a date comes out in 1970 you passed milliseconds as seconds; if it lands tens of thousands of years in the future you did the reverse. JavaScript uses milliseconds, most Unix tooling and databases use seconds, and mixing them is the most common bug this tool surfaces.
What is the year 2038 problem?
A signed 32-bit integer overflows on 19 January 2038 at 03:14:07 UTC, which is the largest timestamp it can hold. Systems still storing time in a 32-bit signed field will wrap to 1901. Modern platforms use 64-bit time, which is safe for about 292 billion years, but embedded systems and old database columns remain a real migration task.
Does Unix time include leap seconds?
No, and this is a genuine subtlety. Unix time is defined as the number of seconds since the epoch excluding leap seconds, so it repeats a value during a positive leap second rather than counting it. This means Unix time is not a true count of elapsed SI seconds. For most applications it does not matter; for precision timing it does.
Why does my timestamp show a different time than expected?
A Unix timestamp is always UTC. It carries no time zone. The local time shown depends on your device settings. If a stored timestamp appears an hour out, suspect a daylight saving conversion applied somewhere it should not have been, not the timestamp itself.
Last reviewed
