Unix timestamp converter — epoch to date, and date back to epoch
Paste an epoch value and read it as ISO 8601, UTC, your own time zone and a plain relative phrase, or fill in a date and get the integer back. The unit is detected from the digit count — 10 digits is seconds, 13 is milliseconds, 16 is microseconds, 19 is nanoseconds — and shown, so a millisecond value is never silently read as seconds and dated to the year 55840. Negative timestamps work, because dates before 1970 are real. Nothing is uploaded or saved.
- Nothing is uploaded or saved
- Works offline
Read as seconds — that is what the digit count suggests. Set the unit yourself if the guess is wrong; a millisecond value read as seconds dates to the year 55840, which is how the mistake announces itself.
Pick a date and a time and the epoch value appears here, in all four units. The time is read as a wall-clock reading in the zone selected above — the same wall clock means a different instant in every zone, which is the whole reason the zone is a control and not an assumption.
- Time duration calculator — if the question is how long something took rather than when it happened — hours between two clock times, totalled and converted to decimal for payroll.
- Days calculator — if you are counting whole days between two dates, or working days with weekends excluded. It never touches a timestamp, which is why it cannot be wrong across a daylight saving boundary.
- Age calculator — if the timestamp you are decoding is a date of birth and what you actually want is the age in years, months and days.
How it works
- 1
Paste the number
Anything a log or a database gives you: 1700000000, 1700000000000, or the 19-digit form Go writes. Commas, spaces and Rust-style underscores are stripped, and a decimal point is kept — Python’s time() returns 1700000000.123456 and that should convert rather than fail. Everything below recalculates as you type; there is no Convert button.
- 2
Check the unit it picked, and override it if it is wrong
The detected unit is printed next to the field, not hidden. Detection is by digit count and it is right for real data, but a small number is genuinely ambiguous — 1000 is a valid timestamp in all four units — so the unit is a control you can set. This is the failure everyone hits once: a millisecond value read as seconds lands in the year 55840, and a seconds value read as milliseconds lands two weeks after the epoch.
- 3
Read the instant in a named time zone
The page detects your zone from the browser and names it — “Asia/Kuala_Lumpur”, not “+08:00”. Pick any other IANA zone from the list to see the same instant on someone else’s wall clock. The conversion comes from the zone database your browser already carries, so daylight saving, half-hour zones and the historical offsets that changed decades ago are all handled by the same data your operating system uses.
- 4
Or go the other way
Enter a date and a time, pick the zone it is written in, and the epoch integer comes back in all four units. Two answers are not simply arithmetic and the page says which one you have hit: a wall-clock time inside a spring-forward gap never happened, and a wall-clock time inside an autumn fall-back happened twice. The first of the two is returned, and both cases are labelled rather than resolved quietly.
- 5
Or just take the current timestamp
The live readout at the top ticks every second and copies in seconds or milliseconds with one press — for most visitors that is the whole errand. It starts blank and fills in after the page loads, because this site is prerendered to static HTML at build time and a clock baked into that file would show the moment the site was built.
Frequently asked questions
What is a Unix timestamp?
A single integer counting seconds since 1 January 1970 at 00:00:00 UTC, which is called the epoch. Zero is that moment exactly. 1700000000 is 14 November 2023 at 22:13:20 UTC — paste it above and check. It is one number for the whole world: it carries no time zone, no daylight saving and no calendar, which is why almost every database, log file and API stores time this way and converts to something readable only at the edges.
Is my number in seconds or milliseconds?
Count the digits. Ten digits is seconds for any date between 2001 and 2286, which covers everything you are likely to be handed. Thirteen is milliseconds — that is what JavaScript’s Date.now() returns. Sixteen is microseconds, which is what Python’s datetime and PostgreSQL timestamps produce. Nineteen is nanoseconds, Go’s UnixNano. You can check the guess instead of trusting it: force 1700000000000 to be read as seconds above and it dates to 8 November 55840, which is how a wrong unit announces itself.
Can a timestamp be negative?
Yes, and this page handles them. A negative value counts backwards from the epoch: −1 is 31 December 1969 at 23:59:59 UTC, and −86400 is 31 December 1969 at 00:00:00, exactly one day before zero. Dates of birth, historical records and migrated database columns all carry them. Many web converters return “Invalid Date” for anything below zero, which is a bug in the converter and not a property of the timestamp.
What is the year 2038 problem?
Older systems store the timestamp in a signed 32-bit integer, and the largest value that fits is 2³¹ − 1, or 2,147,483,647. Paste that above: it is 19 January 2038 at 03:14:07 UTC. One second later the counter overflows and wraps to the most negative value it can hold, which reads as 13 December 1901. Anything storing time in 64 bits — which is every current language, database and operating system by default — is unaffected for a span far longer than the age of the universe. The problem is real but it is a problem about old systems and embedded devices, not about the format.
Why does the same number show a different date for me and my colleague?
Because you are both right. The timestamp is one instant; the calendar date is that instant seen from somewhere. 1700000000 is 14 November 2023 at 22:13:20 UTC, and in Kuala Lumpur, eight hours ahead, the same instant is 15 November at 06:13:20 — a different day of the month, from one number. That is exactly why the zone is a visible control on this page rather than an assumption, and why storing local time in a database instead of an epoch value causes so much grief later.
Why does this page ask for a zone name rather than an offset?
Because an offset is what a zone happens to be at one moment, not what the zone is. “Asia/Kuala_Lumpur” has been +08:00 since 1982, and before that it was +07:30, +09:00 and other values — a fixed offset gets historical timestamps wrong. For zones with daylight saving the offset changes twice a year, so “−05:00” is New York in January and wrong in July. There are also zones an offset picker usually omits: India is +05:30 and Nepal is +05:45. Every conversion here goes through the named zone in your browser’s IANA database, and no offset is computed by hand.
Do Unix timestamps include leap seconds?
No, deliberately. Unix time defines every day as exactly 86,400 seconds, so the count stays a simple multiple and any date can be derived by division. Real astronomical time has needed occasional extra seconds inserted, and Unix time absorbs them by repeating or stretching a second rather than by counting further. The practical consequence is that the difference between two Unix timestamps is not exactly the number of physical seconds that elapsed between them, but it is off by only a handful of seconds across the entire history of the format — far less than the clock error on most machines.
What do the ISO 8601 forms mean, and which do I want?
The form ending in “Z” — 2023-11-14T22:13:20Z — is the instant written in UTC, and it is the one to store or send in an API, because it is unambiguous anywhere. The form with an offset, such as 2023-11-15T06:13:20+08:00, is the same instant written on a particular wall clock and is what you want when the local reading matters. The bare form with neither, 2023-11-14T22:13:20, is what many SQL columns and CSV exports hold, and it is the dangerous one: nothing in the text says which zone it belongs to, so it means whatever the reader assumes.
Does anything I paste leave my browser?
No. The conversion runs in the JavaScript this page already loaded, and the entire time zone database it uses is the one already inside your browser — reached through Intl, not fetched. So there is no request of any kind, this page works with the network switched off, and nothing is written to localStorage, so closing the tab leaves nothing behind. That matters here because the timestamps people bring to a converter usually come out of production logs.