Epoch / Unix Timestamp Converter
Unix time counts seconds since midnight UTC on 1 January 1970. It is the closest thing computing has to a universal instant, and it is the source of a small set of bugs that appear in every codebase eventually.
How to use it
- Enter a Unix timestamp in seconds.
- UTC, your local time, and the ISO 8601 form are shown together.
- Everything is computed in the page.
Seconds or milliseconds: the bug everyone writes once
Unix time is defined in seconds, and most systems use it that way: database timestamp columns, JWT exp and iat claims, HTTP date arithmetic, and essentially all of POSIX.
JavaScript is the significant exception. Date.now and the Date constructor both work in milliseconds, and this mismatch produces the most common date bug in web development.
The symptoms are unmistakable once you recognise them. Feed a seconds value to JavaScript unmultiplied and you land in January 1970, because 1.7 billion milliseconds is about three weeks after the epoch. Feed a milliseconds value to something expecting seconds and you land around the year 56000.
The quick check is digit count. A current timestamp in seconds has ten digits; in milliseconds it has thirteen. Anything with ten digits starting with 17 is a seconds value from the mid-2020s.
The 2038 problem
A signed 32-bit integer holds a maximum of 2,147,483,647, which as a Unix timestamp is 03:14:07 UTC on 19 January 2038. One second later it overflows to the most negative value, which reads as December 1901.
This is not purely historical. Sixty-four-bit systems have long since moved to 64-bit time, which pushes the limit past the lifetime of the sun, but 32-bit time values persist in embedded systems, older database schemas with a 32-bit integer column, some file formats, and network protocols with fixed-width fields.
It also arrives early wherever code computes future dates. A 30-year mortgage schedule or a long-dated certificate expiry crosses the boundary well before 2038 does, which is why the first real 2038 failures have already occurred.
Leap seconds, and what Unix time does about them
Unix time is defined as the number of seconds since the epoch not counting leap seconds. That definition is convenient and slightly false: it means a Unix timestamp is not a true count of elapsed seconds, and the mapping to real time has small discontinuities.
When a leap second is inserted, the same Unix timestamp covers two real seconds. Most systems handle this by smearing the adjustment across a day rather than repeating a value, which keeps time monotonic at the cost of running very slightly slow.
For application code this almost never matters. It matters for anything measuring intervals with sub-second precision across a leap second boundary, which is why systems that care use a monotonic clock for durations and wall-clock time only for timestamps.
Timezones, and why you should store UTC
A Unix timestamp has no timezone. It identifies an instant, and rendering it as a local time is a display decision made with a timezone database.
That is exactly the property you want for storage. Store the instant, convert for display. Storing local times means every read has to know which zone was intended, and daylight saving transitions make some local times ambiguous and others nonexistent.
The local time shown here uses your browser timezone, which is why it differs from UTC by your current offset and why that offset changes across a daylight saving boundary.
The ISO 8601 form is the right choice for interchange. It sorts correctly as text, carries an explicit offset, and no locale misreads it.
At a glance
| Input | Unix timestamp in seconds |
|---|---|
| Outputs | UTC, browser local time, ISO 8601 |
| Negative values | Supported, dates before 1970 |
| Transmitted | Nothing |
Frequently asked questions
My timestamp converts to 1970. What went wrong?
You almost certainly have milliseconds where seconds were expected, or the reverse. A current seconds value has ten digits; a milliseconds value has thirteen.
Why does the local time differ from UTC?
A Unix timestamp is an instant with no timezone. Local time applies your browser current offset, which also shifts across daylight saving boundaries.
Is the 2038 problem still relevant?
On 64-bit systems, no. It persists in embedded devices, 32-bit integer database columns, and fixed-width protocol fields, and it arrives early in any code computing dates decades ahead.
Should I store dates as timestamps or strings?
Store an instant, either as a Unix timestamp or as UTC in a proper timestamp column, and format for display. Storing local times without an offset makes some values ambiguous and others impossible.
Read more
Timestamps, permissions, subnets, and cron — Four operational primitives with unintuitive semantics, and the specific failures each one causes.