Epoch Calculator
Every computer system on Earth agrees on one thing: what time it is. The way they agree is the Unix epoch - the number of seconds (or milliseconds) that have passed since midnight on January 1, 1970, UTC. The Epoch Calculator converts in both directions: paste in a Unix timestamp and get the human-readable date and time, or pick a date and time and get the timestamp back. It also shows the ISO 8601 format, your local time, the day of the week, and the current timestamp - everything you need to work with epoch time in one place.
Epoch timestamps are everywhere once you know to look: database records, log files, APIs, JSON payloads, file metadata, and scheduling systems all store time as a single integer. They are compact, timezone-free, and unambiguous - but utterly unreadable to humans. A value like 1700000000 means nothing at a glance, yet it represents a precise moment: November 14, 2023, at 22:13:20 UTC. This calculator bridges that gap instantly, in both directions, with no sign-up and no fuss.
What Is Unix Epoch Time?
Unix epoch time (also called POSIX time or Unix time) is defined as the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 - a moment known as "the epoch." That date was chosen in the early days of Unix as a convenient fixed reference point, and it has since become the de facto standard for representing time in computing.
The beauty of epoch time is its simplicity. A date-time like "March 5, 2024, 3:30 PM Pacific" bundles together a calendar date, a clock time, and a timezone - three things that must all be parsed correctly. The epoch timestamp for that same moment is a single integer, 1709597400, with no ambiguity: it means the same instant everywhere on Earth, regardless of timezone, daylight saving, or locale formatting.
There are two common units. Seconds precision (10 digits today, e.g. 1700000000) is the classic Unix timestamp used in databases and APIs. Milliseconds precision (13 digits, e.g. 1700000000000) is standard in web browsers, where the built-in clock returns milliseconds, and in many modern web APIs. Our calculator handles both - just tell it which unit your number uses.
Why Developers and Analysts Need Epoch Conversion
If you work with data, you will meet epoch timestamps constantly. Log files record events as epoch integers; converting a suspicious entry to a readable date is step one of any investigation. APIs return created_at and updated_at fields as timestamps; databases store them as integers for efficient sorting and comparison. JSON web tokens encode expiry as epoch seconds.
Debugging is the most common use case. A timestamp in an error report, a cache expiry that misbehaves, a scheduled job that fired at the wrong hour - all of these become clear the moment you convert the number to a date. The reverse direction matters too: setting a token to expire in 24 hours means computing now + 86400, and verifying a cron schedule means converting your intended date to the timestamp the system expects.
Timezone bugs are the other great use case. Because epoch time is inherently UTC, converting a timestamp shows you the one true moment - and comparing the UTC result with the local-time result in our calculator immediately reveals whether a discrepancy is a real bug or just a timezone display difference.
How the Conversion Works
Converting a timestamp to a date is conceptually simple: add the timestamp (in seconds) to the epoch (January 1, 1970, 00:00:00 UTC). The complexity is all in calendar arithmetic - leap years, varying month lengths, and timezone offsets - which is why you let the calculator (or your programming language's date library) do it rather than attempting it by hand.
The reverse conversion - date to timestamp - subtracts: it computes the seconds between the epoch and your chosen date-time. One subtlety: when you pick a date in the calculator's date-time field, it is interpreted in your browser's local timezone, then converted to the UTC-based timestamp. A date entered as midnight in New York and the same date entered as midnight in London produce different timestamps, five hours apart - correctly, because they are different moments.
Milliseconds versus seconds is the classic trap. If your 10-digit timestamp converts to a date in 1970, you probably pasted milliseconds into the seconds field (or vice versa: a 13-digit number in the seconds field gives a date tens of thousands of years in the future). Our calculator's unit selector exists precisely to prevent this mistake - and if you ever see the year 1970 or the year 50000, check the unit first.
How to Use the Epoch Calculator
- To convert a timestamp to a date: paste the number into the Unix Timestamp field, select Seconds or Milliseconds to match, and click Calculate.
- To convert a date to a timestamp: leave the timestamp field alone, pick a date and time in the date-time field (interpreted in your local timezone), and click Calculate. The timestamp rows will show the result.
- Read the results: UTC date and time, ISO 8601 format, your local time, day of the week, the timestamp in both seconds and milliseconds, and the current timestamp for reference.
- Click Reset to restore the default example values and start over.
Tip: the current timestamp row is useful on its own - it tells you "now" as an epoch integer, which you can copy into expiry calculations (add 3600 for one hour, 86400 for one day) or log queries.
Worked Example 1: Timestamp 1700000000 to Date
Let's convert the timestamp 1700000000 (seconds) step by step, the way the calculator does it:
Step 1 - Confirm the unit: 10 digits means seconds. In milliseconds this would be 1,700,000,000,000.
Step 2 - Anchor at the epoch: start from January 1, 1970, 00:00:00 UTC and add 1,700,000,000 seconds.
Step 3 - Convert to days: 1,700,000,000 / 86,400 = 19,675.93 days after the epoch - roughly 53.87 years.
Step 4 - Resolve the calendar date: counting forward through leap years lands on November 14, 2023.
Step 5 - Resolve the clock time: the fractional 0.93 of a day is about 22.3 hours, giving 22:13:20 UTC.
Step 6 - Derived formats: ISO 8601 gives 2023-11-14T22:13:20.000Z; the day of the week is Tuesday; in milliseconds the timestamp is 1700000000000.
This particular timestamp is famous in developer circles - it was widely shared as a round-number milestone ("1.7 billion seconds") in late 2023. The calculator reproduces all of this instantly.
Worked Example 2: Date to Timestamp
Now the reverse: convert January 1, 2030, 00:00 local time to a timestamp. (The exact numeric result depends on your timezone; we will work it for UTC to show the method.)
Step 1 - Interpret the input: 2030-01-01T00:00 in the viewer's local timezone. For UTC, that is exactly midnight UTC.
Step 2 - Count the days: from 1970-01-01 to 2030-01-01 is 60 years, including 15 leap days (1972 through 2028), totaling 21,915 days.
Step 3 - Convert to seconds: 21,915 x 86,400 = 1,893,456,000.
Step 4 - Verify by converting back: feeding 1893456000 into the timestamp field returns 2030-01-01 00:00:00 UTC, confirming the round trip.
Step 5 - Note the timezone effect: the same date entered from New York (UTC-5) would give 1,893,474,000 - 18,000 seconds (5 hours) later - because midnight Eastern is 05:00 UTC. This is correct behavior, and it is why the calculator shows both UTC and local results.
If you are setting a future expiry or scheduling a job, this is the workflow: pick the local date-time you mean, read off the timestamp, and hand that integer to the system.
Seconds vs. Milliseconds: Avoiding the Classic Mistake
The single most common epoch bug is unit confusion. Browser clocks return milliseconds (13 digits); Python's time.time() returns seconds as a float; many databases store seconds as integers; some APIs use milliseconds. Mixing them produces spectacularly wrong dates.
The symptoms are diagnostic. A date in January 1970 means you treated milliseconds as seconds (dividing the true value by 1000 lands near the epoch). A date tens of thousands of years in the future means you treated seconds as milliseconds. Whenever a conversion looks absurd, check the digit count first: 10 digits is seconds, 13 is milliseconds.
Our calculator makes the unit explicit with a selector, and it always displays both units in the results - so you can copy the milliseconds value straight into browser code or the seconds value into a Unix command without a second conversion step.
Timezones, DST, and the 2038 Problem
Epoch time itself has no timezone - it counts absolute seconds since a UTC moment. Timezones enter only when converting to or from human-readable form, which is why the calculator shows UTC and local side by side. Daylight saving transitions, which make some local times ambiguous or nonexistent, do not affect the timestamp at all - another reason systems prefer integers internally.
Leap seconds are the one wrinkle: UTC occasionally inserts a leap second, but Unix time pretends each day is exactly 86,400 seconds, so the timestamp drifts from true astronomical time by the accumulated leap seconds (currently 27). For everyday use this is irrelevant; for scientific precision, use TAI or GPS time instead.
The famous Year 2038 problem: signed 32-bit integers max out at 2,147,483,647, which is January 19, 2038, 03:14:07 UTC. Systems still storing timestamps in 32-bit integers will overflow then - the same class of bug as Y2K. Modern systems use 64-bit integers, for which the problem is billions of years away. If you maintain legacy systems, 2038 is worth auditing long before it arrives.
Tips for Working with Epoch Time
- Count the digits: 10 = seconds, 13 = milliseconds. This one check prevents the most common bug.
- Think in UTC: do all timestamp math in UTC and convert to local time only for display. The calculator's UTC row is your source of truth.
- Use the current-timestamp row: for "now plus X" calculations, take the current value and add seconds (3600/hour, 86400/day, 604800/week).
- Remember date inputs are local: the date-time picker uses your browser timezone. For UTC-exact conversions, mentally adjust or verify against the UTC row.
- Store as integers: if you control the schema, store epoch as a 64-bit integer - sortable, compact, and immune to format ambiguity.
- Beware float precision: millisecond timestamps as floats lose precision; keep them as integers or strings in JSON.
- Test the round trip: convert date to timestamp and back. If you do not land where you started, a timezone or unit error is hiding somewhere.
- Audit for 2038: if any system you touch stores timestamps in 32-bit signed integers, flag it now - January 2038 is closer than it feels.
Frequently Asked Questions
1. What is the Epoch Calculator?
It converts Unix timestamps to human-readable dates and human-readable dates back to timestamps, showing UTC time, ISO 8601, local time, day of the week, and both seconds and milliseconds forms.
2. What is Unix epoch time?
The number of seconds (or milliseconds) since 00:00:00 UTC on January 1, 1970. It is the standard way computers represent a point in time as a single number.
3. Why January 1, 1970?
It was chosen by the early Unix developers as a convenient fixed reference date. The choice stuck and became the POSIX standard used across virtually all modern systems.
4. What is the difference between seconds and milliseconds timestamps?
Seconds precision uses 10 digits (e.g. 1700000000) and is classic Unix time; milliseconds uses 13 digits (e.g. 1700000000000) and is standard in web browsers. They represent the same moment at different precision.
5. My conversion shows a date in 1970 - what went wrong?
You almost certainly pasted a milliseconds timestamp into the seconds field. Switch the unit selector to Milliseconds and recalculate.
6. How do I convert the current time to epoch?
Click Calculate with no date entered and read the "Current Timestamp" row - or in code, use the browser clock value divided by 1000, or time.time() in Python.
7. What is ISO 8601 format?
An international standard date-time format like 2023-11-14T22:13:20.000Z, where T separates date and time and Z denotes UTC. It sorts chronologically as plain text, which makes it ideal for logs and filenames.
8. Does epoch time account for timezones?
No - and that is the point. A timestamp identifies one absolute moment worldwide; timezones only affect how that moment is displayed. The calculator shows both UTC and your local rendering.
9. What is the Year 2038 problem?
Signed 32-bit timestamps overflow at 03:14:07 UTC on January 19, 2038. Systems using 64-bit integers are unaffected. It is worth auditing any legacy 32-bit systems before then.
10. Can timestamps represent dates before 1970?
Yes, as negative numbers - e.g. -86400 is December 31, 1969. The calculator handles negative timestamps the same way.
11. How many seconds are in a day, hour, or year for timestamp math?
86,400 per day, 3,600 per hour, 604,800 per week, and 31,536,000 per (non-leap) year. Unix time ignores leap seconds, so every day is exactly 86,400 seconds.
12. Why does my date-to-timestamp result differ from a colleague's?
Almost always timezones: the date picker interprets input in each browser's local timezone. The same wall-clock time in different zones is a different moment, hence a different timestamp.
13. Are leap seconds included in Unix time?
No. Unix time pretends every day has exactly 86,400 seconds, so it slowly drifts from astronomical time. The accumulated difference is currently 27 seconds and irrelevant for normal use.
14. What timestamp format do web developers use?
Milliseconds since epoch, as returned by Date.now(). When pasting a JS timestamp into this calculator, select Milliseconds.
15. Is the Epoch Calculator free?
Yes. Convert timestamps and dates in both directions as many times as you need, free of charge.
CONCLUSION
The Epoch Calculator does one job and does it completely: it translates between the integers computers use for time and the dates humans understand, in both directions, with both precision units, and with UTC, local, ISO, and weekday context on every conversion. Whether you are debugging a log file, setting a token expiry, untangling a timezone bug, or just curious what 1700000000 means, paste the number or pick the date and get an instant, unambiguous answer. Time is the one thing every system agrees on - this calculator makes sure you agree with it too.