Unix Timestamp Converter
Paste an epoch timestamp to see the date it stands for, in UTC, your own time and the world's main time zones β or pick a date and time to get its timestamp. Seconds, milliseconds, microseconds and nanoseconds are told apart by length, and you can override the guess.
seconds
milliseconds
Timestamp to date
- UTC (ISO 8601)
- Your time
- Relative to now
The same instant in every unit
| Unit | Value |
|---|
Around the world
| Time zone | Date and time |
|---|
Date to timestamp
- Seconds
- Milliseconds
- UTC (ISO 8601)
What a Unix Timestamp Is
A Unix timestamp counts the seconds since 00:00:00 UTC on 1 January 1970, a moment known as the Unix epoch. It is a single number that means the same instant everywhere, which is why logs, databases, APIs and tokens use it: there is no time zone to get wrong, no date format to parse, and comparing two timestamps is just comparing two numbers.
That same property is also the catch. A timestamp says nothing about where or in what unit it was recorded, so turning one back into a date means making two decisions the number does not carry: which unit it is in, and which time zone to show it in.
Seconds, Milliseconds, Microseconds or Nanoseconds?
The original Unix clock counts seconds, but many platforms count something finer. For dates near the present, the number of digits gives the unit away:
| Unit | Digits today | The same instant |
|---|---|---|
| seconds | 10 | 1790000000 |
| milliseconds | 13 | 1790000000000 |
| microseconds | 16 | 1790000000000000 |
| nanoseconds | 19 | 1790000000000000000 |
The converter uses exactly that rule when the unit is set to auto-detect, and says which reading it chose. When the chosen reading lands far from the present, it also shows what the number would mean in a different unit β the usual sign that a value in milliseconds was treated as seconds, or the other way around.
Which Unit Your Language Gives You
Most mix-ups come from moving a timestamp between two systems that count in different units. These are the common defaults:
| Platform | Current time | Unit |
|---|---|---|
| JavaScript | Date.now() |
milliseconds |
| Python | time.time() |
seconds, with a fraction |
| Java | System.currentTimeMillis() |
milliseconds |
| Go | time.Now().Unix() |
seconds |
| Go | time.Now().UnixNano() |
nanoseconds |
| C# / .NET | DateTimeOffset.UtcNow.ToUnixTimeSeconds() |
seconds |
| PHP | time() |
seconds |
| Shell | date +%s |
seconds |
| PostgreSQL | EXTRACT(EPOCH FROM now()) |
seconds, with a fraction |
| MySQL | UNIX_TIMESTAMP() |
seconds |
JavaScript is the odd one out that catches people most often. Date.now() and getTime() return milliseconds, so a value from the browser passed to a backend that expects seconds lands tens of thousands of years in the future, while a seconds value passed into new Date() lands in January 1970.
A Timestamp Has No Time Zone
A Unix timestamp is always UTC-based: it counts from midnight UTC on 1 January 1970, and the same number is the same instant in Tokyo and in Chicago. Time zones only come into it when a person reads the date, which is why this page shows one timestamp as several different local times rather than several different timestamps.
The reverse direction is the one that needs care. Converting a date to a timestamp requires knowing whose clock the date was read from, so the date-to-timestamp form asks for a time zone. Around daylight saving changes a local time can be missing β skipped when the clocks go forward β or repeated when they go back. The converter tells you when either happens instead of quietly picking an answer.
Leap Seconds Are Not Counted
Unix time treats every day as exactly 86,400 seconds. When a leap second is added to UTC, Unix time does not count it: the clock repeats or smears a second, depending on the system. That makes timestamp arithmetic simple β a day is always 86,400 β at the cost of Unix time being slightly out from the true number of seconds elapsed since 1970. For almost every application this does not matter, and it is why no converter, this one included, shows leap seconds.
The Year 2038 Problem
Systems that store Unix time in a signed 32-bit integer run out of room at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. One second later the value wraps to a large negative number, which reads as December 1901. Modern operating systems and languages use 64-bit time, but embedded devices, old file formats and database columns declared as 32-bit integers still carry the limit.
Dates after the limit already turn up today β in certificate expiry dates, long loans and mortgages, and far-future placeholder values β so it is worth checking now. The converter flags any timestamp outside the 32-bit range.
Timestamps Worth Knowing
Click any of these to load it into the converter above.
| Timestamp | What it is |
|---|---|
| The Unix epoch itself: 1 January 1970, 00:00:00 UTC. | |
| One billion seconds: 9 September 2001, 01:46:40 UTC. | |
| The last second a signed 32-bit time_t can hold: 19 January 2038, 03:14:07 UTC. | |
| One second before the epoch: 31 December 1969, 23:59:59 UTC. | |
| Midnight UTC on 1 January 2100 β a date beyond the 32-bit limit. | |
| A present-day value in milliseconds, 13 digits long. |
Related Tools
The exp, iat and nbf claims in a JSON Web Token are Unix timestamps in seconds, and a millisecond value in exp is a classic bug. Check a token's expiry with the JWT Decoder.
Scheduled jobs are the other place time zones decide whether something happens when you expect. See an expression's next run times with the Cron Parser.
API payloads carry timestamps as numbers or strings, and a malformed field is easier to spot once the document is formatted. Tidy the payload with the JSON Formatter.
UUID version 7 puts a millisecond Unix timestamp in its first 48 bits, which is what makes those IDs sort by creation time. Generate time-ordered IDs with the UUID Generator.
References
- The Open Group Base Specifications: Seconds Since the Epoch
- IETF RFC 3339: Date and Time on the Internet: Timestamps
- IANA Time Zone Database
Frequently Asked Questions
How do I convert a Unix timestamp to a date?
Paste it into the converter above. It works out whether the number is in seconds, milliseconds, microseconds or nanoseconds from its length, then shows the date in UTC, in your own time zone and in several others, along with how long ago or how far ahead it is. You can override the detected unit if the guess is wrong.
How can I tell if a timestamp is in seconds or milliseconds?
Count the digits. A present-day timestamp in seconds has 10 digits, in milliseconds 13, in microseconds 16 and in nanoseconds 19. If a converted date comes out in 1970, it was probably seconds read as milliseconds; if it lands tens of thousands of years ahead, it was milliseconds read as seconds.
Is a Unix timestamp in UTC or local time?
Neither, strictly β it is a count of seconds since midnight UTC on 1 January 1970, so it identifies one instant that is the same everywhere. It has no time zone of its own. A time zone only applies when you display it as a date, which is why the same timestamp shows as different local times around the world.
What happens to Unix time in 2038?
Systems that store it in a signed 32-bit integer can count only up to 2,147,483,647, reached at 03:14:07 UTC on 19 January 2038. One second later the value overflows to a negative number and reads as a date in 1901. Systems using 64-bit time are unaffected; the risk is in older software, embedded devices and 32-bit database columns.
Does Unix time include leap seconds?
No. Unix time defines every day as exactly 86,400 seconds, so when UTC adds a leap second, Unix time does not count it. This keeps date arithmetic simple, at the cost of Unix time differing slightly from the true number of seconds that have elapsed since 1970.
Why does the date I converted come out an hour off?
Usually because the date was read in one time zone and converted in another, or because it falls close to a daylight saving change. When converting a date to a timestamp, set the time zone to the one the date was actually recorded in. The converter warns you when the time you entered is skipped or repeated by a daylight saving change.