Unix Timestamp Converter
Epoch time to a readable UTC date and back, in seconds, milliseconds, microseconds or nanoseconds, with the weekday and the ISO-8601 string.
Unix Timestamp Converter: with the default inputs, result is Tuesday, November 14, 2023 at 22:13:20 UTC.
The number as it appears in the log or the database column.
A ten-digit number is almost always seconds; thirteen digits is milliseconds.
Used when converting the other way.
- ISO 8601 (UTC)
- 2023-11-14T22:13:20Z
- Day of the week
- Tuesday
- Seconds since the epoch
- 1,700,000,000
- Milliseconds since the epoch
- 1,700,000,000,000
- Relative to the epoch
- 53.9 years after 1 January 1970
Assumptions
- Unix time is counted in UTC and ignores leap seconds: every day is treated as exactly 86,400 seconds.
- Dates use the proleptic Gregorian calendar, so results before 1582 differ from contemporary Julian-calendar records.
- Sub-second precision is truncated, not rounded, when a millisecond or finer timestamp is reduced to seconds.
| Unit | Value | Where you see it |
|---|---|---|
| Seconds | 1,700,000,000 | Unix time proper — C, Go, PostgreSQL, most log formats |
| Milliseconds | 1,700,000,000,000 | JavaScript Date.now(), Java, Kafka |
| Microseconds | 1,700,000,000,000,000 | Python time_ns()/1000, some databases |
| Nanoseconds | 1,700,000,000,000,000,000 | Go time.UnixNano(), Prometheus |
| ISO 8601 | 2023-11-14T22:13:20Z | Interchange, APIs, logs meant to be read |
How this is worked out
The formula
days = floor(seconds ÷ 86,400) rest = seconds − days × 86,400 → hours, minutes, seconds date = the civil date that many days after 1970-01-01 (UTC) The other direction is the same arithmetic run backwards: seconds = days_since_1970 × 86,400 + hours × 3,600 + minutes × 60 + seconds
Open How it’s calculated above to see this worked through with your own numbers.
What you enter
- Convert
- Choose one of 2 options.Timestamp → date · Date → timestamp
- Timestamp
- The number as it appears in the log or the database column.whole numbers only · defaults to 1700000000
- Timestamp is in
- A ten-digit number is almost always seconds; thirteen digits is milliseconds.Seconds · Milliseconds · Microseconds · Nanoseconds
- Date (UTC)
- Used when converting the other way.defaults to today
- Hour(under More options)
- A number.from 0 to 23 · whole numbers only · defaults to 0
- Minute(under More options)
- A number.from 0 to 59 · whole numbers only · defaults to 0
- Second(under More options)
- A number.from 0 to 59 · whole numbers only · defaults to 0
What you get back
- Resultmain answer
- ISO 8601 (UTC)
- Day of the week
- Seconds since the epoch
- Milliseconds since the epoch
- Relative to the epoch
What this assumes
- Unix time is counted in UTC and ignores leap seconds: every day is treated as exactly 86,400 seconds.
- Dates use the proleptic Gregorian calendar, so results before 1582 differ from contemporary Julian-calendar records.
- Sub-second precision is truncated, not rounded, when a millisecond or finer timestamp is reduced to seconds.
About this calculator
Unix time is a single integer: the number of seconds since midnight UTC on 1 January 1970. That is all of it. Everything confusing about timestamps comes from the two things that integer does not tell you.
It is always UTC, and it is not really "seconds since 1970"
A Unix timestamp has no time zone. If a log says 1700000000 and you are in Chicago, the moment it names is 14 November 2023 at 22:13 UTC — 16:13 where you are sitting. Converting it "to local time" is a display choice made after the fact, not something stored in the number.
The second subtlety catches people out more rarely but more painfully: Unix time deliberately ignores leap seconds. It counts as though every day has exactly 86,400 seconds, which is why the arithmetic here is simple division and why a Unix timestamp is not a count of elapsed SI seconds since 1970. It is a count of days and seconds-of-day, encoded as one number.
Working out which unit you have
The commonest mistake is reading milliseconds as seconds, which throws the answer roughly 50,000 years into the future. Count the digits:
- 10 digits — seconds. Anything between 1,000,000,000 (September 2001) and 9,999,999,999 (November 2286).
- 13 digits — milliseconds. JavaScript's
Date.now(), Java, Kafka. - 16 digits — microseconds. Python's
time_ns()/1000, some database drivers. - 19 digits — nanoseconds. Go's
UnixNano(), Prometheus.
If a converted date lands in 1970 or in the year 54,000, the unit is wrong rather than the number.
The 2038 problem
Timestamps stored in a signed 32-bit integer run out at 03:14:07 UTC on 19 January 2038, when the count passes 2,147,483,647 and wraps to a date in December 1901. Modern systems use 64 bits and are fine for about 292 billion years, but embedded devices, old file formats and some database columns are not. This converter flags any result past that point.
Dates before 1970
Negative timestamps are perfectly legal and mean a moment before the epoch. Plenty of software rejects them anyway, so if you are storing historical dates, a timestamp is often the wrong column type — a plain date is clearer and does not invite a time-zone bug.
Frequently asked questions
▸What time zone is a Unix timestamp in?
UTC, always. The number itself carries no zone — it counts seconds from midnight UTC on 1 January 1970. Showing it in local time is something your code does afterwards, and getting that step wrong is the single most common timestamp bug.
▸How do I tell seconds from milliseconds?
Count the digits. Ten digits is seconds for any date between 2001 and 2286; thirteen is milliseconds. If a timestamp converts to a date in 1970 you have divided when you should not have, and if it converts to the year 54,000 you have read milliseconds as seconds.
▸Does Unix time count leap seconds?
No. It assumes every day is exactly 86,400 seconds long, so the 27 leap seconds inserted since 1972 are simply skipped — a leap second and the second after it share a timestamp. This is why Unix time is not a true count of elapsed seconds, and why it stays easy to convert.
▸What happens in 2038?
At 03:14:07 UTC on 19 January 2038 a signed 32-bit timestamp reaches its maximum of 2,147,483,647 and wraps round to December 1901. Anything using 64-bit time is unaffected, which is nearly everything modern, but embedded firmware and old file formats are the ones to check.
▸Can a timestamp be negative?
Yes, and it means a moment before 1970 — minus 86,400 is 31 December 1969. The arithmetic is well defined, but a lot of software refuses negative values, so they are a poor way to store historical dates.
Put this calculator on your own site
A working unix time, free for any site, with no ads and no sign-up. It resizes to fit wherever you paste it and updates itself as this page improves.
Paste this anywhere. It works on any site, carries no ads, never expires, and always shows the current version.
Unix Timestamp Converter by CalculateItNow
The page's own title. The clearest description of what the link leads to.
The credit line sits outside the widget on purpose, so it is a real link on your page rather than one buried in a frame. Please keep it — it is what pays for CalculateItNow staying free and ad-free. The script only resizes the widget to fit its contents; drop it and the widget still works.
Browse every calculator widget·How to add it to WordPress, Squarespace or Wix
Related calculators
The questions people ask next to a unix time.
Convert a date and time between world time zones using real IANA zone data, so daylight saving is applied correctly rather than a fixed, half-wrong offset.
Days, weeks, months and business days between two dates, or add and subtract days, weeks, months or years from any date — leap years handled exactly.
What day of the week a date falls on, plus its day number in the year, ISO week number, leap-year status, and that date's weekday in nearby years.
The exact time between two dates and times in days, hours, minutes and total seconds, plus the working hours it covers under your own working-day definition.
Add or subtract two durations in hours, minutes and seconds and get the result as h:mm:ss, decimal hours, total minutes and seconds — with the carrying shown.