Unix Timestamp Converter
Convert Unix timestamps to readable dates and dates back to epoch time. Supports seconds and milliseconds. See the current timestamp live.
Current Unix Timestamp
Saturday, October 31, 2026 at 08:34:25 AM UTC
Timestamp → Date
Date → Timestamp
Or type: 2024-01-15 14:30:00
How to convert a Unix timestamp
Convert a timestamp to a date, or a date to a timestamp, in seconds or milliseconds.
- 01
Copy the current timestamp if that's all you need
The live clock at the top shows the current Unix time in seconds, ticking every second, with its date underneath.
- 02
Turn a timestamp into a date
Paste the number and pick seconds or milliseconds. You get the date in your local time zone and in UTC.
- 03
Turn a date into a timestamp
Pick a date and time in the picker. It's read in your device's time zone, and you get the timestamp in both seconds and milliseconds.
What a Unix timestamp counts
A Unix timestamp is the number of seconds since midnight UTC on 1 January 1970, ignoring leap seconds. It's the same number everywhere in the world at a given moment, which is why databases, APIs and log files use it: there's no time zone to get wrong. Time zones only come in when you turn it into a date for a person to read.
| Timestamp (seconds) | Date and time | Why it's interesting |
|---|---|---|
| 0 | 1 January 1970, 00:00:00 UTC | The epoch itself |
| 1,700,000,000 | 14 November 2023, 22:13:20 UTC | A recent round number |
| 1,735,689,600 | 1 January 2025, 00:00:00 UTC | |
| 2,000,000,000 | 18 May 2033, 03:33:20 UTC | The next 10-digit milestone |
| 2,147,483,647 | 19 January 2038, 03:14:07 UTC | Largest signed 32-bit value |
| 4,294,967,295 | 7 February 2106, 06:28:15 UTC | Largest unsigned 32-bit value |
The 2038 row is the reason for the "Year 2038 problem". Systems that store time as a signed 32-bit number run out at 03:14:07 UTC on 19 January 2038 and wrap round to 1901. Modern operating systems, databases and languages use 64-bit time, but old embedded devices and some file formats don't.
Seconds or milliseconds: the mistake to avoid
Unix timestamps are usually in seconds, a 10-digit number today. JavaScript's Date.now(), Java's System.currentTimeMillis() and many APIs use milliseconds, 13 digits. Read one as the other and the date is wildly wrong: 1700000000 treated as milliseconds is 20 January 1970, and a millisecond value treated as seconds lands tens of thousands of years in the future.
So count the digits before converting. 10 digits is seconds, 13 is milliseconds, and 16 is usually microseconds, which you can divide by 1,000 to get milliseconds.
Quick maths with timestamps
Because a timestamp is just seconds, date arithmetic becomes addition. One hour is 3,600 seconds, one day 86,400 and one week 604,800. So a token that should expire in seven days gets exp = now + 604,800. The difference between two timestamps, divided by 86,400, is the number of days between them.
That simplicity is also why time zones never belong in the number itself. Store and compare timestamps in UTC seconds, and only convert to a local date when you show it to someone.
Where timestamps show up
Reading timestamps in logs and databases
Paste a created_at value to see when something actually happened, in your own time zone.
Checking token expiry
Convert a JWT's exp or iat claim to see whether a token has expired.
Setting a scheduled time in an API call
Pick the date and time you want and copy the seconds value into the request.
Limits worth knowing
- Dates you pick are read in your device's time zone. To get a timestamp for midnight UTC, set your system zone or adjust by your offset.
- Leap seconds aren't counted, which matches how Unix time is defined.
- Dates are limited to what JavaScript can represent: about 271,000 years either side of 1970.