What next?
Epoch time converts to a date, then to a duration.
How to use this tool
- Enter a Unix timestamp, or a date and time.
- It converts both directions automatically.
- Read the local time, UTC and Unix value.
What your result means
A Unix timestamp is the number of seconds since 1 January 1970 UTC — a compact, timezone-free way to store a moment. The tool shows it as your local time and UTC so you can line up logs and API responses.
Why this one is different
Thirteen digits are read as milliseconds and re-dated for you instead of landing in the year 58,000, and anything past the 2038 ceiling of a signed 32-bit clock is flagged. The zone behind the date side is stated outright, including the hour that does not exist each spring and the hour that repeats each autumn. ISO 8601, RFC 1123, milliseconds, relative wording and the ISO week all arrive together.
Timestamps worth recognising
| Timestamp | UTC instant | Why it matters |
|---|---|---|
| 0 | 1 Jan 1970, 00:00:00 | The epoch. A date of 1970 in a UI usually means a missing value. |
| 1000000000 | 9 Sep 2001, 01:46:40 | Ten digits begin here — anything shorter predates 2001. |
| 2147483647 | 19 Jan 2038, 03:14:07 | The last second a signed 32-bit clock can express. |
| 4294967295 | 7 Feb 2106, 06:28:15 | The ceiling for an unsigned 32-bit clock. |
Digit count is the quickest sanity check: ten digits is a plausible modern timestamp in seconds, thirteen is the same instant in milliseconds, and anything with sixteen is microseconds from a database or a tracing tool.
The clock the whole internet counts by
A Unix timestamp is simply the number of seconds elapsed since midnight UTC on 1 January 1970 — the "epoch". Storing time as one integer sidesteps time zones, formats and languages, which is why databases and APIs love it.
There's a famous catch: 32-bit systems run out of room on 19 January 2038. Modern 64-bit systems push that limit billions of years away.
Related tools
What a Unix timestamp counts
A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, the "epoch". It is a single integer with no timezone, no daylight-saving rules and no locale — which is exactly why systems use it internally and convert to human time only at the edges. JavaScript and many APIs use milliseconds since the same epoch, so a value that looks a thousand times too large is usually a millisecond timestamp.
Worked example
Converting the Unix timestamp 1700000000:
UTC Tue, 14 Nov 2023 22:13:20 GMT
That is the number of seconds elapsed since midnight UTC on 1 January 1970, ignoring leap seconds. Your local time will differ from the UTC line by your current offset — and by an extra hour during daylight saving, which is why storing timestamps rather than local times avoids an entire category of bug.
Storing time correctly is a decision you make once
The rule that prevents almost every timezone bug: store instants in UTC, convert to local only when displaying, and keep the user's timezone as a separate field if you need to know it. Local time in the database looks convenient for about six months, until a daylight-saving change makes one hour ambiguous and another hour nonexistent, and no amount of later correction can recover which was which.
Daylight saving is more hostile than it looks. In the UK, 01:30 occurs twice on the October clock change and never on the March one, so a timestamp written as local time on those days can be genuinely unresolvable. Timezone rules also change by political decision — several countries have shifted or abolished DST in the last decade — so a date far in the future converted to local time today may convert differently by the time it arrives.
For durations, prefer arithmetic on Unix seconds and convert at the end. For calendar operations — this day next month, the third Tuesday — do the arithmetic in local calendar terms instead, because "a month" is not a fixed number of seconds. Mixing the two is the source of most off-by-one-day bugs.
Frequently asked questions
Why does my timestamp show the wrong time?＋
Almost always a units or timezone mismatch. Check whether the value is in seconds or milliseconds — a 13-digit number is milliseconds — and remember that the timestamp itself is UTC, so it will differ from local clock time by your offset.
What is the 2038 problem?＋
Systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038 and wrap to a negative number. Modern systems use 64-bit time values, which push the limit roughly 292 billion years out, but embedded and legacy software can still be affected.
Does Unix time account for leap seconds?＋
No. Unix time deliberately pretends every day is exactly 86,400 seconds, and repeats or skips a value when a leap second occurs. This keeps date arithmetic simple at the cost of being marginally out of step with astronomical time.
What is the difference between seconds and milliseconds?＋
Unix time is defined in seconds, but JavaScript, Java and many APIs use milliseconds. A timestamp of ten digits is seconds, thirteen is milliseconds, and mixing them puts the date around 1970 or far into the future.
Should I store times in UTC or local time?＋
UTC, always, converting to local only for display. Local storage breaks the moment a daylight saving change or a second timezone enters the picture.
What is ISO 8601 and why use it?＋
The international standard date format, such as 2026-08-02T14:30:00Z. It sorts correctly as plain text, is unambiguous about day and month order, and carries its offset explicitly.
Assumptions & limitations
Unix time is exact; interpreting it as a wall-clock time is where assumptions enter:
- Displayed local times use your device's timezone and its current daylight-saving rules, which have changed historically and will change again.
- Unix time ignores leap seconds, so it is not a count of elapsed SI seconds since the epoch.
- Every value you type is read as whole seconds. A thirteen-digit entry is flagged as milliseconds and re-dated in the notes rather than rescaled behind your back, and microsecond values are not handled at all.
- Signed 32-bit timestamps overflow in January 2038. Systems still using them will need 64-bit values before then.