Unix Timestamp Converter
Convert Unix timestamps to dates and dates to timestamps, in seconds, milliseconds, microseconds or nanoseconds, with UTC and local readings.
Last reviewed: 30 July 2026
Related calculators
-
Time Zone Converter
Convert a time between any two cities, with DST handled.
-
Week Number Calculator
Find the ISO week number for a date, or the dates in a week.
-
Date Difference Calculator
Find the exact gap between two dates in every useful unit.
-
Time Duration Calculator
Measure the time between two clock times, even past midnight.
-
Meeting Time Planner
Find meeting slots that work across several countries.
How Unix timestamps work
A Unix timestamp counts the seconds elapsed since midnight UTC on 1 January 1970, known as the Unix epoch. Because it is a single number tied to UTC, it identifies one instant unambiguously — no time zone, no daylight saving, no date format to misread.
Units and the digit-count trick
The same instant can be expressed in seconds, milliseconds, microseconds or nanoseconds, and confusing them is the most common bug in date-handling code. For dates in the current era:
- 10 digits — seconds. Used by Unix, PHP and most APIs.
- 13 digits — milliseconds. Used by JavaScript and Java.
- 16 digits — microseconds. Used by Python's
datetimeand PostgreSQL. - 19 digits — nanoseconds. Used by Go and by some time-series databases.
The unit is detected from magnitude, and the result always states which one was applied. You can override it if you are working with a historic date where the digit count is ambiguous.
Negative timestamps
Dates before 1970 are represented as negative numbers: −86400 is 31 December 1969. Not every system handles these correctly, so test carefully if you are storing historic dates.
The Year 2038 problem
A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. Systems still storing time in 32 bits will wrap round to 1901. Most current systems use 64-bit values, which are good for roughly 292 billion years.
Leap seconds
Unix time treats every day as exactly 86,400 seconds and ignores leap seconds entirely. It is therefore not a true count of elapsed SI seconds since 1970 — it is a count of days multiplied out, which is precisely what makes the arithmetic tractable.
Worked example
Timestamp 1767225600
- Ten digits, so it is a seconds timestamp.
- 1767225600 ÷ 86,400 = 20,454 whole days since the epoch.
- That lands on 1 January 2026, 00:00:00 UTC.
- In London that is also 00:00 on 1 January, because the UK is on GMT in January.
- In New York it is still 19:00 on 31 December 2025.
Reference points
| Landmark | Seconds | Meaning |
|---|---|---|
| Unix epoch | 0 | 1 January 1970, 00:00:00 UTC |
| Signed 32-bit overflow | 2,147,483,647 | 19 January 2038 — the "Year 2038 problem" for 32-bit signed timestamps |
| Signed 32-bit minimum | -2,147,483,648 | 13 December 1901 — the earliest date a 32-bit signed timestamp can hold |
| One billion seconds | 1,000,000,000 | 9 September 2001 |
| Two billion seconds | 2,000,000,000 | 18 May 2033 |
Frequently asked questions
Is my timestamp in seconds or milliseconds?
Count the digits. A current timestamp in seconds has 10 digits, milliseconds has 13, microseconds 16 and nanoseconds 19. The converter detects this automatically and always tells you which unit it used, so a misread number cannot silently produce a date in 1970 or in the year 57000.
What is the Unix epoch?
Midnight UTC on 1 January 1970. A Unix timestamp is simply the number of seconds elapsed since that moment, which is why it is also called epoch time or POSIX time.
What is the Year 2038 problem?
A signed 32-bit integer can hold at most 2,147,483,647, which as a seconds timestamp is 03:14:07 UTC on 19 January 2038. Systems still using 32-bit time will overflow to a negative number and read the date as 1901. Most modern systems use 64-bit values and are unaffected.
Do timestamps have a time zone?
No, and this is the point of them. A timestamp identifies a single instant, the same everywhere. A time zone is only applied when you display it, which is why the result shows the UTC reading and a local reading side by side.
Are leap seconds included?
No. Unix time deliberately ignores leap seconds, treating every day as exactly 86,400 seconds. This keeps the arithmetic simple but means Unix time is not a true count of elapsed SI seconds since 1970.