Enter a timestamp or date above to convert.
What Is a Unix Timestamp?
A Unix timestamp is the number of seconds since 00:00:00 UTC on January 1, 1970, not counting leap seconds. A 10-digit number is seconds and a 13-digit number is milliseconds: 1,800,000,000 falls on January 15, 2027 at 08:00 UTC. Paste any timestamp above to get UTC, local and ISO 8601 dates, or turn a date back into a timestamp.
A Unix timestamp (also called Epoch time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. It is the universal standard for storing and transmitting time in software systems, used by every major operating system, database, and programming language. The current Unix time is shown live at the top of this tool, updating every second.
Because it is a simple integer, Unix time is easy to store, compare, and calculate. Subtracting two timestamps gives the exact duration between them. Adding 86,400 gives exactly one day later in UTC (a local calendar day can last 23 or 25 hours when daylight saving time changes). This simplicity is why it became the global standard despite numbers like 1768175999 looking abstract to human eyes.
Seconds vs. Milliseconds
Standard Unix timestamps count in seconds and are 10 digits long (e.g. 1768175999). JavaScript and many modern APIs use milliseconds instead, producing 13-digit numbers (e.g. 1768175999000). This converter detects automatically based on digit count.
For developers: use this tool to verify API responses, debug time-based bugs, and convert log timestamps into readable dates. Combine with our Timezone Converter and World Clock for full time zone coverage.
Seconds, Milliseconds or Something Else?
The converter picks the unit from the size of the number. You can override it with the Input Unit menu.
| Unit | Digits today | Example (same moment) | Typical source |
|---|---|---|---|
| Seconds | 10 | 1800000000 | Unix date +%s, PHP time(), most APIs and JWT exp claims |
| Milliseconds | 13 | 1800000000000 | JavaScript Date.now(), Java System.currentTimeMillis() |
| Microseconds | 16 | 1800000000000000 | PostgreSQL internals, Python time.time_ns() // 1000 |
| Nanoseconds | 19 | 1800000000000000000 | Go UnixNano(), time.time_ns() |
Auto-detect rules: below 100 billion is read as seconds (that covers every date up to the year 5138), up to 14 digits as milliseconds, 15 to 17 digits as microseconds and 18 or more as nanoseconds. Very large nanosecond values lose a little precision in the browser, but never enough to change the millisecond.
Timestamp Milestones
| Timestamp (seconds) | UTC date and time | Why it matters |
|---|---|---|
| 0 | Jan 1, 1970 00:00:00 | The Unix epoch |
| 1,000,000,000 | Sep 9, 2001 01:46:40 | First 10-digit timestamp |
| 1,234,567,890 | Feb 13, 2009 23:31:30 | The "1234567890" moment |
| 1,700,000,000 | Nov 14, 2023 22:13:20 | Recent round number |
| 1,800,000,000 | Jan 15, 2027 08:00:00 | Next round number |
| 2,000,000,000 | May 18, 2033 03:33:20 | 2 billion seconds |
| 2,147,483,647 | Jan 19, 2038 03:14:07 | Last second a signed 32-bit counter can hold |
| 4,294,967,295 | Feb 7, 2106 06:28:15 | Limit of an unsigned 32-bit counter |
| 10,000,000,000 | Nov 20, 2286 17:46:40 | Timestamps grow to 11 digits |
The Year 2038 Problem in Practice
A signed 32-bit integer tops out at 2,147,483,647. One second later, at 03:14:08 UTC on January 19, 2038, it wraps to −2,147,483,648, which software reads as 20:45:52 UTC on December 13, 1901. Linux and the major operating systems have used a 64-bit time_t on 64-bit hardware for years, and 64-bit counters last for billions of years. The risk sits in places nobody looks at often:
- MySQL
TIMESTAMPcolumns, which stop at 2038-01-19 03:14:07 UTC.DATETIMEor aBIGINTavoids it. - File formats and network protocols with a fixed 32-bit time field.
- Embedded devices, older 32-bit builds and firmware that will still be running in 2038.
- Any code that already handles future dates, such as 30-year loan schedules or certificates, which can fail well before 2038.
Test by feeding 2147483648 (one past the limit) into the system and checking that it reads as 2038, not 1901.
Get the Current Timestamp in Code
| Language or tool | Seconds | Timestamp to date (UTC) |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Python 3 | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('c', $ts) |
| Java 8+ | Instant.now().getEpochSecond() | Instant.ofEpochSecond(ts) |
| Go | time.Now().Unix() | time.Unix(ts, 0).UTC() |
| C# | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | DateTimeOffset.FromUnixTimeSeconds(ts) |
| Bash (GNU) | date +%s | date -u -d @1800000000 |
| PostgreSQL | extract(epoch from now()) | to_timestamp(ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) (session time zone) |
Common mistakes
- Mixing units. Passing seconds to
new Date()in JavaScript gives a date in January 1970. Multiply by 1,000 first. - Treating local time as UTC. A timestamp has no time zone. The zone only appears when you format it, so always say which one you used.
- Adding 86,400 for "tomorrow" in local time. On daylight saving change days a local day lasts 23 or 25 hours. Add calendar days in a date library instead.
To convert the resulting time between cities, use the time zone converter; for the gap between two dates, the days between dates calculator.