Epoch Converter: Unix Timestamp to Date and Back

How to use this tool

The dark bar at the top is the current Unix time, ticking once a second, with the millisecond version and the same moment written out in UTC and in your own time zone. Copy seconds puts the number on your clipboard; Use now loads it into both panels below so you can work from it.

The left panel turns a timestamp into a date. Paste any number and the converter reads the digit count to decide whether it is seconds, milliseconds, microseconds or nanoseconds, then shows the moment in UTC, in your local time and in any zone you pick from the list. Below that are the same instant as ISO 8601, RFC 2822, day of year and ISO week, and as an Excel serial number and a Julian Day, each with its own copy button. The right panel goes the other way: pick a date, a time and the zone that time was read in, and you get the timestamp in seconds and milliseconds.

The input people most often get wrong is the unit. A 13 digit number is not a date in the year 55,000; it is milliseconds, which is what JavaScript and Java hand out. The converter says when it has guessed a unit, and the unit picker overrides it. The second trap is the zone on the date to timestamp side: a date typed without a zone is read as UTC, so choose your own zone if the date came from a local clock.

The batch box takes one value per line, timestamps and dates mixed, and converts the lot into a table. Download results CSV exports whichever you have: the batch table if there is one, otherwise the single conversion with every representation. Print or save as PDF produces a one page report, and Copy link gives an address that reopens the converter on the same value.

What Unix time actually counts

Unix time is one integer: the number of seconds since 00:00:00 UTC on January 1, 1970. That starting point is called the epoch, and it was chosen by the people writing Unix in the early 1970s because it was a round date close to the present. Nothing about it is astronomical or special; it is a convention that stuck because every system that adopted it could exchange times as plain numbers.

The number carries no time zone, no calendar and no daylight saving. It is the same value in Halifax, Karachi and Tokyo at the same instant. That is its whole point. Zones only appear when the number is turned into a date for a person to read, and that is where all the disagreements come from. Two servers logging 1700000000 agree completely; two people reading it in different places see different clock times.

Turning the number into a date is arithmetic, not lookup. Divide by 86,400 to get whole days since 1970, then walk those days through the Gregorian calendar with its leap year rule, and the remainder gives the time of day. The converter does exactly that and never asks the browser for the date, which is why it produces the same answer on every machine.

Seconds, milliseconds and the 13 digit tell

Every timestamp for a date between September 2001 and November 2286 has ten digits when it is in seconds. Add three digits and it is milliseconds, six more and it is microseconds, nine more and it is nanoseconds. That is the whole trick for telling them apart, and the converter uses it: 1700000000 and 1700000000000 are the same moment, one in seconds and one in milliseconds.

Which unit you get depends on where the number came from. JavaScript, Java, Kotlin and C# time functions return milliseconds. Python, PHP, Ruby, Go, Unix shells and nearly all databases return seconds. Log files from high frequency systems and some cloud services use microseconds or nanoseconds. Paste a millisecond value into a function expecting seconds and you get a date in the year 55,000, which is the most common epoch bug there is.

One more thing about the big numbers. JavaScript, and therefore this page, holds integers exactly up to 2 to the power of 53, about 9 quadrillion. A nanosecond timestamp is around 1.7 quintillion, so its last two or three digits cannot be held exactly. The seconds and milliseconds are always right; the converter warns when a value is past that limit.

Time zones do not exist in a timestamp

Because the number is zone free, the converter shows every timestamp three ways: UTC, your browser’s zone, and a zone you choose. The zone list comes from the browser’s own IANA database, the same one your operating system uses, so daylight saving rules are current without this page having to store them.

Going the other way is where zones bite. If you type November 14, 2023 at 17:13:20 and say it was Eastern Time, the converter gives 1700000000; say it was UTC and you get 1699982000, five hours earlier. Pick the zone the clock was in when the time was written down, not the zone you are in now.

Daylight saving creates two awkward cases, and the converter handles both rather than guessing silently. On the spring forward night, a time such as 02:30 in New York never happens; the converter tells you so and uses the moment the clocks read after the jump. On the fall back night, 01:30 happens twice; the converter takes the first one, the daylight time reading, which is what most software does.

A worked check you can repeat on paper

Take 1,700,000,000. Divide by 86,400 seconds in a day: 19,675 whole days with 80,000 seconds left over. The 80,000 seconds are 22 hours (79,200) plus 800 seconds, which is 13 minutes and 20 seconds, so the time of day is 22:13:20.

Now place the days. From January 1, 1970 to January 1, 2023 is 53 years, of which 13 were leap years (1972 through 2020), so 53 × 365 + 13 = 19,358 days. That leaves 19,675 minus 19,358 = 317 days into 2023, and day 318 of a non leap year is November 14. So 1,700,000,000 is November 14, 2023 at 22:13:20 UTC, a Tuesday. The converter reports exactly that, and the day of the week follows because January 1, 1970 was a Thursday and 19,675 days is 2,810 weeks and 5 days.

Go the other way to check: 19,675 days × 86,400 = 1,699,920,000, plus 22 × 3,600 = 79,200, plus 13 × 60 = 780, plus 20, is 1,700,000,000 again.

The year 2038 problem

A signed 32 bit integer tops out at 2,147,483,647. As a Unix timestamp that is 03:14:07 UTC on Tuesday, January 19, 2038. One second later the bits roll over to minus 2,147,483,648, which reads as December 13, 1901, and anything that trusted the number breaks: certificates look expired, schedules run backwards, sorted records land in the wrong order.

Desktop and server operating systems, current languages and mainstream databases moved to 64 bit time years ago, and a 64 bit count of seconds lasts about 292 billion years. The problem lives in what did not move: embedded controllers, old routers and set top boxes, file formats and network protocols with 32 bit fields, and database columns someone declared as INT instead of BIGINT a long time ago. The converter flags any timestamp past the limit so you know a value is in that territory.

Getting the epoch in code

The same two operations in the languages and tools people ask about most. Replace ts with the timestamp in seconds; for milliseconds, divide by 1,000 first or use the millisecond variant your language offers.

Mistakes that catch people out

Feeding milliseconds to a seconds function. The result is a date around the year 55,000, or an error about the value being out of range. Count the digits: 13 means divide by 1,000 first.

Reading a date as local when it was UTC, or the reverse. The error is exactly your zone offset, which is why a timestamp that comes out a few hours wrong almost always has this cause. Decide which zone the human readable date was written in before converting it.

Storing timestamps in a 32 bit column. It works today and fails in 2038. Use BIGINT, a 64 bit integer type, or the database’s own timestamp type.

Expecting midnight to be the same moment everywhere. Midnight on January 1, 2027 in UTC is 1798761600; midnight in Halifax is four hours later at 1798776000. A date without a time and zone is not one instant, it is a range of them.

Subtracting timestamps to get calendar days. Dividing a difference by 86,400 gives elapsed 24 hour periods, which differ from calendar days across a daylight saving change. For day counts use the Date Duration Calculator, which works on calendar dates.

Trusting the last digits of a nanosecond value in a spreadsheet or in JavaScript. Both hold about 15 to 16 significant digits, and a nanosecond timestamp has 19. Keep those as text, or split them into seconds and a fraction.

Notable Unix timestamps

The values people look up by number: the round billions, the ones programmers celebrated, and the limits of 32 bit storage. Each link opens the converter on that value with its own address.

Unix timestamp for the start of each year

Midnight UTC on January 1 for every year from the epoch to 2040. Useful as range boundaries in queries and for checking which year a timestamp belongs to.

Current, relative and day boundary timestamps

These are worked out from the moment you open the page, so the number is always live: the current timestamp, the start and end of today, this week, this month and this year in UTC, and fixed offsets from now.

Epoch converter by time zone

Each link opens the converter set to that zone, with the current time in the zone as the starting point. The zone applies to both directions: timestamps show in that zone, and dates typed in that zone convert back correctly, including daylight saving.

How this was checked

The date arithmetic is written from scratch rather than borrowed from the browser, so it was checked against the browser. Twenty thousand random timestamps between 1906 and 2160 were converted to a date by the converter’s own calendar algorithm and by the JavaScript Date object in UTC; every year, month, day, hour, minute, second and weekday matched, and every date converted back to the original timestamp.

Known values were checked by hand: 0 is January 1, 1970; 1,000,000,000 is September 9, 2001 at 01:46:40 UTC; 1,234,567,890 is February 13, 2009 at 23:31:30 UTC; 2,147,483,647 is January 19, 2038 at 03:14:07 UTC; minus 2,147,483,648 is December 13, 1901 at 20:45:52 UTC. ISO week numbers were checked against the awkward year boundaries, such as January 3, 2021 being week 53 of 2020, and the Excel serial for 1,700,000,000 was confirmed as 45244.925926.

Time zone conversion was checked in both directions for New York, Halifax and India, including the two daylight saving edge cases: 02:30 on March 8, 2026 in New York resolves to 07:30 UTC and is flagged as a time that does not exist, and 01:30 on November 1, 2026 resolves to the first of its two occurrences.

Common questions

What is Unix epoch time?

Unix time is the number of seconds that have passed since 00:00:00 UTC on January 1, 1970, a moment called the epoch. It is a single integer that grows by one every second, which makes it easy to store, compare and subtract. 1,700,000,000 is November 14, 2023 at 22:13:20 UTC.

Is a Unix timestamp in UTC or local time?

A timestamp is the same number everywhere; it has no time zone. Time zones only appear when the number is turned into a calendar date. 1700000000 is 22:13 in London, 17:13 in New York and 03:43 the next morning in India, and all three are the same instant.

How do I tell seconds from milliseconds?

Count the digits. Timestamps for dates between 2001 and 2286 have 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. JavaScript, Java and Kotlin hand out milliseconds by default; Python, PHP, Go and most databases use seconds. The converter detects the unit from the length and lets you override it.

What is the year 2038 problem?

Systems that store Unix time as a signed 32 bit integer can count no higher than 2,147,483,647, which is 03:14:07 UTC on January 19, 2038. One second later the value wraps to a large negative number and reads as December 1901. Modern operating systems, languages and databases use 64 bit time; the risk is in old embedded devices, file formats and database columns declared as INT.

Does Unix time count leap seconds?

No. Every day is exactly 86,400 seconds in Unix time, so the 27 leap seconds added since 1972 are not counted; when one occurs, the clock repeats a second or smears it over a period. This is why Unix time is not the same as the number of physical seconds elapsed, and why converting it back to a date never needs a leap second table.

Can a Unix timestamp be negative?

Yes. Negative values are moments before 1970. The timestamp of the Moon landing, July 20, 1969 at 20:17 UTC, is minus 14,182,980. Most languages handle negatives, though some older functions and databases reject them.

Related Calculators and Reference

• Date Duration Calculator: the gap between two dates in calendar days, weeks and months, for when subtracting timestamps is not the right tool.
• Days From Today Calculator: the date a number of days, weeks or months from now lands on, which is the calendar side of the relative timestamps above.
• Military Time Converter: 24 hour clock to 12 hour and back, for reading the times this page produces.
• Binary, Hex and Decimal Converter: see what 2,147,483,647 looks like in binary and why it is the 32 bit limit.
• Age Calculator: years, months and days from a date of birth, the human readable version of a large timestamp difference.
• POSIX: Seconds Since the Epoch: the standard that defines how the count works and confirms that leap seconds are left out.