Unix Timestamp Converter

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.

Core formulas for Unix time conversion

Conceptually, converting between Unix timestamps and human-readable dates follows straightforward formulas. The details (time zones, leap years, and calendar rules) are implemented for you by the browser or programming language runtime, but it is useful to understand the relationship.

From date to Unix timestamp

In words: take your date and time in UTC, subtract the Unix epoch instant, and express the result as a number of whole seconds.

The relationship can be expressed in MathML as:

Here, t is the moment you care about (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

To go the other way, start from the epoch and add the given number of seconds:

Your system then presents that UTC instant in whatever display time zone you select. This converter uses your browser’s local time zone for the main human-readable output and also shows an ISO 8601 representation tied to UTC.

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 (for example from JavaScript’s Date.now()), you must 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 (for example, 24-hour vs 12-hour clock).
• 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, you will typically see:

• A local date and time: This is often the easiest format to understand at a glance. Use it to answer questions like “When did this log entry occur on my machine?”
• An ISO 8601 string: This format is ideal for storing and exchanging timestamps in APIs and configuration files, because it is explicit about UTC and time zone offsets.
• The original Unix timestamp: Keeping the original number visible helps you double-check that you entered the right units and did not accidentally mix up seconds and milliseconds.

If the result looks off by a fixed number of hours (for example, exactly UTC minus five hours), check whether you are expecting UTC display while the converter is intentionally using your local time zone. Also verify that your system clock and time zone settings are correct.

Worked example: from timestamp to date and back

Suppose you receive a log entry with the Unix timestamp 1700000000. You want to know when that event occurred in your local time and confirm what value to use when replaying the event.

Step 1: Convert the timestamp to a human-readable date

1. Enter 1700000000 into the Unix timestamp field.
2. Click the convert button.
3. The tool calculates the UTC instant that is 1,700,000,000 seconds after 1970-01-01 00:00:00 UTC.
4. Your browser formats that instant into your local time zone and shows both the local representation and an ISO 8601 UTC timestamp.

For example, you might see something like “2023-11-14 22:13:20” in your local time and 2023-11-14T22:13:20Z as the ISO value (the exact local time shown will depend on your offset from UTC).

Step 2: Convert the date back to a Unix timestamp

1. Take the ISO 8601 value 2023-11-14T22:13:20Z as the canonical representation of the instant in UTC.
2. Use the date-and-time picker in the converter to select the equivalent local date and time, or directly enter the date and time if your browser allows.
3. Click the convert button to compute the Unix timestamp.
4. The tool again computes the offset from the Unix epoch and returns 1700000000.

This round trip helps you verify that you have the correct units and that there was no off-by-one error in your calculations or data handling.

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.

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:

• Inspecting server logs to debug production issues.
• Analyzing analytics exports or event streams.
• Setting cookie expirations or cache lifetimes.
• Scheduling background jobs and cron tasks.
• Coordinating events across services in different regions.

Several common pitfalls are worth keeping in mind when interpreting results:

• 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 (January 2 vs. February 1). 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. Comparing values in local time around those transitions can be confusing.

Limitations and assumptions of this converter

While the converter is suitable for most practical purposes, it relies on a few assumptions and has limitations you should know about:

• Time zone handling: Output is formatted using your browser’s configured time zone for the human-readable string and UTC for the ISO 8601 value. If your system or browser time zone is misconfigured, the local-time result will be affected.
• Leap seconds: Standard Unix time ignores leap seconds and assumes days are exactly 86,400 seconds long. This converter follows that convention; it does not simulate leap seconds.
• Date range: The practical range is constrained by the environment in which the tool runs. Most modern browsers support a very wide range of dates (far beyond the historical 32-bit limit), but extremely large or small numbers may not be handled consistently.
• 32-bit vs. 64-bit context: Historically, 32-bit Unix time overflowed around 2038-01-19. This converter itself is not limited to 32-bit values, but external systems you integrate with might be. Always check your target system’s supported date range.
• Seconds precision: The main input and output are in whole seconds. If you work with sub-second precision (milliseconds or microseconds), you must scale values appropriately and be aware that fractional information will be lost when rounding to seconds.

If you compare this converter with other tools or with built-in functions in languages such as JavaScript, Python, or Java, small differences almost always come from time zone assumptions, unit mismatches (seconds vs. milliseconds), or library-specific date range rules rather than from a fundamentally different definition of Unix time.

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. When you see different clock times for the same timestamp, that difference comes from how the viewing tool converts UTC into a display time zone.

How can I tell if my timestamp is in seconds or milliseconds?

A quick rule of thumb is to look at the length and magnitude of the number. Modern timestamps in seconds are around 10 digits long. Values around 13 digits usually represent milliseconds. If a converted date looks far in the past or future, check whether you should divide or multiply by 1,000 before using it.

Why does another converter show a different time for the same value?

Most discrepancies occur because one tool shows results in UTC and another shows them in your local time zone. Both can be correct. Compare the UTC ISO 8601 values if you want a consistent, time-zone-neutral reference.

Can I convert dates before 1970?

Yes. Negative Unix timestamps represent instants before the epoch. This converter supports negative values, although extremely old dates may be limited by browser or operating-system date handling.