Unix Timestamp Converter
Convert Unix timestamps to human-readable UTC dates and back, handling both seconds and milliseconds.
How to use this calculator
- 1To read a timestamp, paste it in — seconds and milliseconds are detected automatically.
- 2To create one, switch direction and enter a date and UTC time.
How the calculation works
Unix timestamp = seconds elapsed since 1970-01-01T00:00:00Z- Epoch
- The reference instant: midnight UTC on 1 January 1970
- Timestamp
- A count of seconds (or milliseconds) since that instant
Unix time deliberately ignores leap seconds. Every day is treated as exactly 86,400 seconds, which keeps the arithmetic simple at the cost of being fractionally out of step with astronomical time.
JavaScript works in milliseconds; most other systems use seconds. Mixing the two is the most common bug in timestamp handling, and produces dates in 1970 or the far future.
Worked example
Converting 1786665600
- 1.The value is under 100 billion, so it is read as seconds.
- 2.1,786,665,600 seconds is about 56.6 years after the epoch.
- 3.That lands on Sunday, 15 August 2026 at 00:00:00 UTC.
Result: 2026-08-15T00:00:00.000Z
What Unix time is and why computers count this way
A Unix timestamp is a single number: the count of seconds that have elapsed since a fixed reference instant — 00:00:00 UTC on 1 January 1970, known as the Unix epoch. Rather than storing a year, month, day, hour, minute and second as separate fields, a system just stores one integer. That has a real practical payoff: comparing two timestamps, measuring the interval between them, or sorting a list of events by time all reduce to plain arithmetic on a single number, instead of juggling calendar rules across five or six separate fields.
1970 itself isn’t significant for any historical reason — it was simply a convenient recent date when Unix was under development in the early 1970s, and it stuck as the reference point almost every later system inherited, from databases to programming languages to the timestamps that appear throughout the web.
Why the same instant looks different everywhere
A timestamp is time-zone-free by construction — it counts seconds from a single fixed instant, so a given timestamp means exactly the same moment in London, Tokyo and New York. What differs is only how that instant gets displayed: converting a timestamp to a local calendar date requires applying a time-zone offset, and in many places seasonal daylight-saving rules, on top of the raw number. This is why storing timestamps rather than pre-formatted local date strings is standard practice in software that needs to work correctly across regions — the underlying instant never needs reinterpreting, only its display does.
Where timestamps turn up
Once you know to look for it, Unix time is everywhere under the hood:
- Database rows — created_at and updated_at columns are almost always stored as a timestamp internally, even when a UI displays a friendlier relative date like "3 days ago".
- API responses — JSON APIs frequently return Unix time for dates, since it needs no time-zone-aware parsing library on the receiving end — just an integer.
- Cache and token expiry — a cache entry’s expiry, or a login token’s exp claim in a JWT, is typically just a future Unix timestamp that gets compared against the current one.
- Log files — server and application logs commonly timestamp every line in Unix time, often alongside a human-readable date, so entries from machines in different time zones can be merged and sorted correctly.
Where the arithmetic goes wrong
A short list of mistakes accounts for most timestamp bugs:
- Seconds versus milliseconds — JavaScript’s Date works in milliseconds, while most other languages and most APIs use seconds. Passing one where the other is expected lands on a date near 1970 (seconds mistaken for something 1,000 times smaller) or tens of thousands of years in the future (milliseconds mistaken for seconds).
- Forgetting the instant is absolute — code that formats a timestamp using the server’s local time zone instead of UTC, or the viewer’s, silently shows the wrong wall-clock time to someone elsewhere, even though the underlying number was always correct.
- The Year 2038 problem — systems that still store Unix time in a signed 32-bit integer will overflow at 03:14:07 UTC on 19 January 2038 and wrap around to 1901 — a real, if shrinking, concern in older embedded systems and file formats built before 64-bit time became standard.
What this assumes, and where it stops
Assumptions
- Timestamps and displayed times are in UTC.
Limitations
- Local time zones are not applied. Converting to your own zone requires knowing its offset and daylight-saving rules on that specific date.
- Leap seconds are not represented, in line with the Unix time standard itself.
- Timestamps before 1970 are negative and are handled correctly, but some systems reject them.
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 to something expecting seconds. If it lands tens of thousands of years in the future, you did the reverse.
What is the Year 2038 problem?
Systems storing Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038, wrapping to 1901. Most modern systems use 64-bit time and are unaffected, but embedded devices and old file formats remain a genuine concern.
Why does Unix time ignore leap seconds?
Because handling them would mean every day was not exactly 86,400 seconds, making date arithmetic dependent on a table of past announcements. The trade-off is that Unix time is a few dozen seconds away from true elapsed time since 1970 — almost always an acceptable price.
Sources
Formula and content last reviewed on .
Results are estimates for information only, not professional advice.
Related calculators
Tools people commonly use alongside the unix timestamp converter.