Epoch time is the count of seconds since 1 January 1970, in UTC, with every day exactly 86,400 seconds. This guide explains the count, the four units, the time zone rules, the leap-second limit, and the Year 2038 problem, with worked conversions throughout.

What epoch time is, in plain words

Epoch time is a count. It counts the seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. The value 0 is that exact moment. The value 1 is one second later. The value 1,735,689,600 is exactly 1 January 2025, 00:00:00 UTC. Every instant in time, past or future, gets exactly one number, and every number names exactly one instant. That one-to-one mapping is the whole point of the system.

Computers prefer a single number to a calendar date written as text, because numbers are trivial to compare, sort, and subtract. A bigger timestamp is always a later moment, with no month lengths, leap years, or date formats to argue about. Two timestamps subtract cleanly into an elapsed time: the difference between two values is the number of seconds between the two instants, whatever dates they fall on. Databases index timestamps as integers for the same reason, and log files sort correctly when their lines carry plain numbers instead of formatted dates.

The epoch date itself was a convenience choice. When Unix was built in the early 1970s, 1 January 1970 was a round, recent starting point, and the count stuck. It stuck so thoroughly that the same count now powers application programming interfaces, databases, log files, JSON web tokens, file timestamps, and most programming languages. When a system hands you a mysterious 10-digit or 13-digit number, the first guess worth testing is always epoch time, and the converter on this site exists to test it in one paste.

Three properties define the count, and every section of this guide returns to them. First, the count is always in UTC, the world time standard, with no time zone built in. Second, every day in epoch math is exactly 86,400 seconds long, because leap seconds are ignored by definition. Third, the count can go negative: negative values are dates before 1 January 1970, counted backwards at the same one-second-per-second pace. Keep those three properties in mind and almost every epoch surprise explains itself.

Seconds, milliseconds, microseconds, nanoseconds

The same instant can be written in four units, and the only difference between them is a factor of 1,000 at each step. Seconds are the classic unit and the one most systems use. Milliseconds are seconds times 1,000, and they are the unit of JavaScript, whose Date.now method returns milliseconds. Microseconds are milliseconds times 1,000 again, and nanoseconds are microseconds times 1,000 a third time. To move to a finer unit you multiply by 1,000; to move to a coarser unit you divide by 1,000. There is nothing else to the conversion, which is why getting the unit wrong is the single most common epoch mistake.

The digit count tells you the unit before you convert anything. A current timestamp in seconds has 10 digits. The same instant in milliseconds has 13 digits, in microseconds 16 digits, and in nanoseconds 19 digits. The table below shows one instant, 1 January 2025 at midnight UTC, written all four ways, so you can match the shape of any number you are handed against a known example.

A shorter number is still seconds, only older. The count started at 0 in 1970 and passed 1,000,000,000, a 10-digit value, on 9 September 2001. Before that date, timestamps in seconds had nine digits: 946,684,800 is 1 January 2000, 00:00:00 UTC, and 0 is the epoch itself. A minus sign means the date falls before 1970: minus 86,400 is one day before the epoch, 31 December 1969, 00:00:00 UTC, and minus 1 is one second before the epoch, 31 December 1969 at 23:59:59 UTC. Negative timestamps are valid values, not errors, and this converter handles them like any other.

Worked conversions make the factor of 1,000 concrete. Take 1,735,689,600 seconds. Multiply by 1,000 and you get 1,735,689,600,000 milliseconds. Multiply by 1,000 again and you get 1,735,689,600,000,000 microseconds. Multiply once more and you get 1,735,689,600,000,000,000 nanoseconds. All four numbers name the same instant, midnight UTC on 1 January 2025, and feeding any of them into the converter with the right unit selected returns the same readable date. Feeding the 13-digit milliseconds value into a seconds field is what produces the famous year 5138 result: the converter faithfully counts 1,735,689,600,000 seconds forward from 1970, and lands more than three thousand years in the future. The fix is never to doubt the date. The fix is to divide by 1,000, or to select Milliseconds as the unit.

UTC, local time, and time zones

Epoch time has no time zone. The timestamp is the instant itself, counted in UTC, and a time zone only changes how that instant is written on a clock face. The value 1,735,689,600 is midnight UTC on 1 January 2025. In New York it is 19:00 on 31 December 2024, because the Eastern clock runs five hours behind UTC in standard time. In Pacific Standard Time it is 16:00 on 31 December 2024, eight hours behind UTC. Three readings, one instant, one timestamp. No conversion of the timestamp itself ever takes place when you cross a time zone: only the display changes.

That distinction resolves the most persistent timezone confusion in epoch work, which is the midnight problem. Converting the bare date 1 January 2025 to a timestamp without naming a time zone is ambiguous, because local midnight falls at a different UTC instant in every time zone. Midnight in New York, midnight in London, and midnight in Sydney are three different timestamps, hours apart. This converter resolves the ambiguity openly: its date-to-epoch field uses your browser local time, so the date and time you enter are read as local, and the timestamp returned is the UTC instant of that local moment. If you need the timestamp for midnight UTC instead, enter the date and time in UTC terms, or convert with the UTC reading shown beside the local reading in the main result.

Daylight time adds one more wrinkle, and it is a display wrinkle, not a timestamp wrinkle. Pacific Time is eight hours behind UTC in standard time, under the name PST, and seven hours behind UTC in daylight time, under the name PDT. A summer date therefore reads one hour later on a Pacific clock than the same UTC instant would read in winter, while the timestamp does not move at all. The same pattern holds everywhere daylight time is observed: the offset changes, the clock reading changes, and the epoch count marches on at one second per second, indifferent to all of it. When someone asks for an epoch time in PST, the honest answer is the UTC timestamp plus the statement of which offset was used to display it.

The count for right now is equally simple to state, if not to memorize: it is the number of seconds since the epoch, still counting, one more every second. That is what phrases like seconds since the epoch and epoch time to now are asking for. A converter that shows the current timestamp is just reading the same count at the moment you look, and a minute later the count is sixty higher. Nothing about the present moment is special in epoch math. It is one more number on the same line, between the past behind it and the future ahead of it.

Converting by hand, both directions

Converting a timestamp to a date by hand is slow, which is why the converter exists, but the method is worth knowing because it shows what the converter is actually doing. Start from the epoch, 1 January 1970, and count forward in days. Every day is 86,400 seconds in epoch math, so divide the timestamp by 86,400 to get whole days plus a remainder. The whole days carry you to a calendar date, allowing for leap years, and the remainder is the seconds since midnight UTC on that date, which divides into hours, minutes, and seconds in the usual way. The converter performs exactly this walk, including the leap-year rules, and it does it instantly, which is the only real difference between the two approaches.

The reverse direction is the same walk backwards. Count the days from 1 January 1970 to your date, multiply by 86,400, then add the seconds since midnight UTC. The worked example on the converter page is 29 February 2024 at 12:00 UTC, a leap day, which comes out as 1,709,208,000 seconds. The leap day matters: 2024 is a leap year, so February has 29 days, and a count that forgot the extra day would land a full 86,400 seconds early. Hand conversion is a good check on a converter result and a good way to understand one, but for any real work, paste the number into the converter and let it count the days.

Two hand checks are worth keeping in your pocket. First, round numbers are landmarks: 0 is the epoch, 1,000,000,000 is 9 September 2001, and 1,735,689,600 is 1 January 2025. If a conversion lands near a landmark you recognize, the unit is probably right. Second, dividing or multiplying by 1,000 moves you exactly one unit step, so a date that lands absurdly far in the future is almost always a unit error, not a data error. Try the next unit down before you conclude the timestamp itself is wrong.

Leap seconds, and why epoch time ignores them

Real days are not all exactly the same length. The rotation of the Earth wobbles slightly, so from time to time an extra second, a leap second, is inserted into UTC to keep clocks aligned with the planet. Epoch time ignores leap seconds entirely, by definition. In Unix time, every day is exactly 86,400 seconds, no exceptions, and a timestamp therefore cannot represent a leap second at all. The count simply pretends the inserted second never happened, and the next second after the leap second carries the number the leap second would have carried in a system that counted it.

For almost all everyday work this fiction is harmless, and it is in fact the reason epoch arithmetic stays simple: subtraction always gives elapsed seconds, with no leap-second table to consult. The cost appears only where sub-second scientific precision matters, or where an exact correspondence with UTC across a leap second is legally or scientifically required. For that work, use a time scale that counts leap seconds, such as TAI, or keep a leap-second table beside your timestamps and apply it explicitly. Do not expect an epoch converter to resolve a leap second for you. The definition of the count forbids it, and any converter that claimed otherwise would be inventing data.

The Year 2038 problem

On 19 January 2038 at 03:14:07 UTC, a signed 32-bit counter of seconds runs out. The largest value such a counter can hold is 2,147,483,647, and one second later it wraps around to a negative number, jumping the apparent date back to December 1901. It is the same class of bug as the Year 2000 problem: a counter with too few digits meeting a date it cannot express. The difference is that the fix has been known for decades, and most of the world has already applied it.

Modern systems use 64-bit counters, which hold seconds for about 292 billion years, far longer than the age of the universe, so anything built or updated in the last decade is safe. The remaining 2038 risk lives in old embedded hardware: industrial controllers, legacy equipment, and file formats designed when 32-bit counters were the standard. If you still see a 2038 warning, it is about that old hardware, not about your phone or your laptop, and not about the converter on this site, which handles the full 64-bit range. The lesson of 2038 is a general one about counting systems: always ask how many digits the counter has before you trust it with a date.

Where epoch time is used

Epoch time shows up wherever a system needs dates that sort, subtract, and compare without ambiguity. Application programming interfaces return creation times as epoch seconds, so a record created field that reads 1,700,000,000 is simply Tuesday, 14 November 2023, at 22:13:20 UTC, waiting to be rendered readably. Databases index timestamps as integers for the same reason, and the ordering of the integers is the ordering of the instants, with no format parsing in between. Log lines carry epoch timestamps so that lines from many machines merge into one correct chronological order, even when the machines sit in different time zones.

Security and caching use the same count. JSON web tokens carry an expiry field that is an epoch timestamp in seconds, and a token is valid only while the current epoch count is below that number. Cache headers express lifetimes as second counts, which are durations rather than timestamps, but they live in the same numeric world and are just as easy to confuse with one. File systems stamp files with epoch times for creation and modification, which is why a file listing can show a bare number where you expected a date. Some platforms show epoch values directly in their own interfaces: chat timestamps in Discord, for example, are stored as epoch seconds and rendered as readable dates by the app. In every case the pattern is the same. The system stores a number, and the readable date is a rendering of that number, produced at display time, in the viewer time zone.

That rendering step is where human confusion enters, and it is the step this converter owns. The converter takes the stored number and produces the UTC date, the local time, the ISO format, and the day of the week, all from the same instant. Paste the number, check the unit by counting digits, and read the date. If the date looks wrong, the unit is almost certainly the problem, and the fix is one step of 1,000 in the right direction.

Common mistakes, and the fix for each

Almost every epoch error belongs to one of a short list, and each has a visible symptom that points straight at the cause. The table below collects them, so a wrong-looking date can be diagnosed in seconds instead of debated.

The deepest of these mistakes is the last one, because it feels like the right thing to do. Adding or subtracting a time zone offset from a timestamp, and then storing the adjusted number, corrupts the data: the stored number no longer names the instant it was meant to name, and every other system that reads it will render a different moment. The rule is absolute and simple. Timestamps stay in UTC, always, from storage to transmission. Time zones enter only at the final step, when a human being looks at the date. Follow that rule and the other mistakes become easy to spot, because a wrong date will always trace back to a unit or a display choice, never to the count itself.

Frequently asked questions

What is epoch time in simple terms?

Epoch time is the number of seconds since 00:00:00 UTC on 1 January 1970. The value 0 is that exact moment, and 1,735,689,600 is 1 January 2025 at midnight UTC. It is how computers store dates as a single number, so dates can be compared, sorted, and subtracted without worrying about formats or time zones.

How do I convert epoch time to a date?

Paste the number into the Epoch Converter and pick the right unit first: 10 digits means seconds, 13 digits means milliseconds. The converter shows the UTC date, your local time, the ISO format, and the day of the week. If the date lands thousands of years in the future, you fed milliseconds into a seconds field, so divide by 1,000 or select Milliseconds.

What is the difference between epoch seconds and milliseconds?

A factor of 1,000. Seconds count whole seconds since the epoch, and milliseconds count thousandths of a second, so the same instant is 1,735,689,600 in seconds and 1,735,689,600,000 in milliseconds. JavaScript timestamps use milliseconds, while most APIs and databases use seconds, which is why the digit count is the fastest way to tell them apart.

Does epoch time change with time zones?

No. The timestamp is always the UTC instant, and a time zone only changes the displayed reading. The value 1,735,689,600 is midnight UTC on 1 January 2025, 19:00 on 31 December 2024 in New York, and 16:00 on 31 December 2024 in Pacific Standard Time. Keep the timestamp in UTC and convert only the display.

Can epoch timestamps be negative?

Yes. Negative values are dates before 1 January 1970, counted backwards at the same pace: minus 86,400 is 31 December 1969, 00:00:00 UTC, and minus 1 is one second before the epoch. Negative timestamps are valid values, not errors, and the converter handles them like any other.

What happens in the Year 2038 problem?

On 19 January 2038 at 03:14:07 UTC, a signed 32-bit counter of seconds reaches its maximum of 2,147,483,647 and wraps to a negative number. Modern systems use 64-bit counters, which last about 292 billion years, so the risk is confined to old embedded hardware. Anything built or updated in the last decade is safe.