Introduction
Unix time is one of the simplest and most common ways computers represent a moment. Instead of storing a full date string such as “November 14, 2023, 22:13:20 UTC,” a system can store a single number like 1700000000. That number is the count of elapsed seconds since the Unix epoch, which begins at 1970-01-01 00:00:00 UTC. Machines like this format because it is compact, easy to compare, and consistent across programming languages, databases, APIs, and operating systems.
People, however, usually do not think in raw epoch seconds. If you are reading server logs, debugging an API response, checking a database record, or preparing a timestamp for code, you often need to translate between the machine-friendly number and a normal date and time. This calculator does both jobs. It converts a Unix timestamp in seconds into a readable local date, a UTC date, and an ISO 8601 value. It also converts a local date and time back into a Unix timestamp so you can paste the result into scripts, queries, or configuration files.
The page is designed to be practical first. You can quickly test the current moment with the Now button, convert a timestamp to a date, or reverse the process by choosing a date and time from your browser’s date-time picker. The result area then shows the same instant in several useful formats so you can compare them without guessing. Below the calculator, you will also find a plain-language explanation of how Unix time works, what the inputs mean, how the formula is defined, a worked example, and the main limitations to keep in mind when comparing results across tools.
How to use
There are two common workflows, and both are supported directly on this page. If you already have a Unix timestamp, use the first form. Enter the number of seconds since the epoch in the Unix timestamp (seconds) field, then select Convert to date. The calculator will interpret the value as whole seconds, create the corresponding instant, and display it in your browser’s local time zone, in UTC, and in ISO 8601 format. If you want a quick test value, press Now to fill the current timestamp automatically.
If you instead know the calendar date and local clock time, use the second form. Pick a value in the Local date and time field and press Convert to timestamp. The calculator treats that input as a local date-time in your browser environment, converts it to the matching UTC instant, and then reports the Unix timestamp in seconds. This is useful when you need to schedule an event, reproduce a log entry, or prepare a timestamp for an API call.
When reading the result, remember that the numeric timestamp itself is time-zone neutral, but the human-readable display is not. The same timestamp can appear as different clock times in different places because each viewer may format the same UTC instant using a different local time zone. That is why the ISO 8601 UTC output is especially helpful: it gives you a standard reference string that is easy to compare across systems.
What is a Unix timestamp?
A Unix timestamp is a single integer that counts the number of elapsed seconds since the Unix epoch. The Unix epoch is defined as 1970-01-01 00:00:00 Coordinated Universal Time (UTC), ignoring leap seconds. A timestamp of 0 represents exactly that instant; positive integers represent moments after it, and negative integers represent moments before it.
Because a Unix timestamp is just a number, it is compact to store, easy to compare, and unambiguous across time zones. A higher number always represents a later point in time. This makes Unix timestamps a natural choice for log files, event streams, message queues, distributed systems, and databases.
Formula
Conceptually, converting between Unix timestamps and human-readable dates follows straightforward formulas. The details such as leap years, month lengths, daylight saving transitions, and locale formatting are handled by the browser’s date engine, but the underlying relationship is simple. A timestamp is the elapsed number of seconds between the moment you care about and the epoch. Going the other direction means starting at the epoch and adding the timestamp value back as seconds.
From date to Unix timestamp, the idea is: take the UTC instant you want, subtract the epoch instant, and express the difference in seconds.
Here, t is the instant being measured in UTC, and t_epoch is 1970-01-01 00:00:00 UTC. The result is the Unix timestamp in seconds.
From Unix timestamp to date, you reverse the process by adding the timestamp to the epoch.
In practice, this calculator accepts timestamps in seconds, not milliseconds. That distinction matters because many JavaScript tools use milliseconds internally. For example, Date.now() returns milliseconds, so you would divide by 1,000 to get the seconds-based Unix timestamp used here. If a converted date looks wildly wrong, the first thing to check is whether your source value is in seconds or milliseconds.
How this converter interprets time zones and units
Unix timestamps themselves do not store any time zone information; they are always defined relative to UTC. However, tools that display timestamps have to choose a time zone for formatting into a human-readable string. This converter makes a few explicit choices so that you know what to expect.
- Input timestamps: The main input is interpreted as a Unix timestamp in seconds since the epoch. If you are working with millisecond values, such as those produced by JavaScript’s
Date.now(), divide by 1,000 before using this tool.
- Local display: The primary human-readable result is shown in your browser’s current local time zone, using your system’s locale for formatting.
- ISO 8601 output: Alongside the local time, the converter shows an ISO 8601 timestamp such as
2024-01-15T12:34:56Z, which is always UTC-based.
- Date to timestamp: When you choose a date and time, the converter treats it as a moment in your local time zone, converts that to UTC, and then calculates the Unix timestamp in seconds.
Because of these rules, if you compare this tool against another converter that defaults to UTC for both input and display, you may see different human-readable strings for the same numeric timestamp. The underlying UTC instant is still the same; only the chosen display time zone differs.
Interpreting your conversion results
Once you run a conversion, the result area gives you several views of the same instant. The local time is usually the easiest one to read quickly because it matches your own environment. The UTC time is useful when you are comparing logs or systems that standardize on UTC. The ISO 8601 value is often the best format for copying into APIs, configuration files, and technical documentation because it is explicit and portable.
The calculator also shows a relative description when converting from a timestamp to a date, such as “2 hours ago” or “In 3 days.” That line is not a separate timestamp format; it is simply a convenience layer that compares the converted instant with your current time. It can help you sanity-check whether a value is roughly where you expect it to be.
If the result looks off by a fixed number of hours, that usually points to a time-zone expectation mismatch rather than a broken timestamp. If the result looks off by decades, that usually means seconds and milliseconds were mixed up. Those two issues account for most timestamp confusion in everyday work.
Example
Suppose you receive a log entry with the Unix timestamp 1700000000. You want to know when that event occurred and verify that you can convert it back correctly. First, enter 1700000000 in the timestamp field and click Convert to date. The calculator interprets that number as 1,700,000,000 seconds after the epoch and displays the corresponding local time, UTC time, and ISO 8601 string.
Depending on your time zone, the local display may differ from someone else’s screen, but the UTC and ISO values refer to the same exact instant everywhere. For example, the ISO output may appear as 2023-11-14T22:13:20Z. If you then choose the equivalent local date and time in the second form and click Convert to timestamp, the calculator should return 1700000000 again. That round trip confirms that the value is being interpreted in seconds and that the local display is only a formatted view of the same UTC moment.
This kind of check is especially useful when debugging logs, replaying events, or comparing timestamps from multiple systems. If the round trip does not come back to the same value, the most likely causes are a unit mismatch, an incorrectly entered local date, or a misunderstanding about which time zone a different tool is using.
Comparison of common time formats
Many systems use different, but related, representations of the same underlying moment in time. The table below summarizes a few of the most common formats you will encounter when working with Unix timestamps and dates.
| Format |
Example value |
Units / structure |
Typical usage |
| Unix timestamp (seconds) |
1700000000 |
Integer number of seconds since 1970-01-01 00:00:00 UTC |
Databases, POSIX systems, many APIs, log files |
| Unix timestamp (milliseconds) |
1700000000000 |
Integer number of milliseconds since the same epoch |
JavaScript Date.now(), some web APIs, analytics tools |
| ISO 8601 (UTC) |
2023-11-14T22:13:20Z |
Structured string with date, time, and Z suffix for UTC |
REST APIs, configuration files, data interchange between systems |
| ISO 8601 with offset |
2023-11-14T17:13:20-05:00 |
Same instant as UTC value, but with explicit time zone offset |
Client-side applications, logs that need local-time context |
| Human-readable local date |
11/14/2023, 5:13:20 PM |
Formatted for a specific locale and time zone |
User-facing UIs, reports, dashboards, emails |
All of these representations can describe the same moment in time. The converter on this page focuses on Unix timestamps in seconds and produces both human-readable local dates and ISO 8601 UTC strings so that you can move between formats confidently.
Typical uses and pitfalls
Unix timestamps appear in many day-to-day development tasks. They show up in server logs, analytics exports, event streams, cache expiration settings, scheduled jobs, and cross-region systems that need a neutral way to describe time. Because the format is so common, it is easy to assume every tool handles it the same way. In reality, most mistakes come from a few recurring misunderstandings.
- Seconds vs. milliseconds: A value like
1700000000 is a plausible timestamp in seconds, but 1700000000000 is likely in milliseconds. If the date looks decades off, check which unit your source system uses.
- Local time vs. UTC: Two tools may show different human-readable times for the same numeric timestamp if one defaults to UTC and the other uses your local time zone.
- Parsing ambiguous strings: Human-readable dates such as
01/02/2024 can be interpreted differently depending on locale. ISO 8601 strings remove that ambiguity.
- Daylight saving transitions: Local wall-clock time can skip forward or repeat during DST changes, even though the underlying Unix time advances smoothly.
When in doubt, compare the ISO 8601 UTC output. It is usually the clearest neutral reference when multiple systems disagree on how to display the same instant.
Limitations
While this converter is suitable for most practical work, it still depends on the browser’s date engine and on standard Unix time conventions. That means there are a few assumptions worth stating clearly. First, the human-readable local output depends on your browser and operating system time-zone settings. If your device is configured incorrectly, the local display will also be incorrect even though the underlying timestamp math is fine.
Second, standard Unix time ignores leap seconds. In other words, it treats time as if every day contains exactly 86,400 seconds. That is the convention used by most software systems, and this calculator follows it. Third, the practical date range is limited by what JavaScript Date supports reliably. Modern browsers handle a wide range, but extremely large or small values may still fall outside the supported range.
Finally, this page works in whole seconds. If your source data uses milliseconds, microseconds, or nanoseconds, you need to scale the value before or after conversion. The calculator is intentionally simple and does not preserve sub-second precision in its main output. For most logging and API tasks that is perfectly fine, but it is important to know when precision matters.
Frequently asked questions
What is the Unix epoch? The Unix epoch is the reference instant 1970-01-01 00:00:00 UTC from which Unix timestamps count elapsed time. A timestamp of 0 corresponds exactly to that moment.
Are Unix timestamps always in UTC? Yes. Unix timestamps are defined relative to UTC and do not store time-zone information. Different clock displays come from formatting choices, not from different timestamps.
How can I tell if my timestamp is in seconds or milliseconds? Modern timestamps in seconds are usually around 10 digits long, while millisecond values are often around 13 digits. If the converted date looks far in the past or future, check the unit first.
Can I convert dates before 1970? Yes. Negative Unix timestamps represent instants before the epoch, although very old dates may be limited by browser support.
