🔢 Unix Timestamp Converter

Last updated: May 27, 2026

Unix Timestamp Converter

Convert epoch timestamps ↔ human-readable dates in any timezone

Current Unix Timestamp
—
UTC Time
—

⟶ Epoch to Human-Readable Date

Enter seconds (10-digit) or milliseconds (13-digit)

⟵ Date & Time to Unix Epoch

Unix Timestamps Decoded: The Number That Powers Every Server Clock on Earth

Open any server log, any database row, any API response from a serious production system, and you will almost certainly find a number like 1719100800 sitting in a column labeled created_at or timestamp. To a human it looks like noise. To a machine it is an unambiguous, perfectly sortable, timezone-free moment in time. That number is a Unix timestamp — and understanding it properly changes how you think about time in software.

What Exactly Is Unix Time?

Unix time (also called POSIX time or epoch time) counts the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — a date known as the Unix epoch. The choice of 1970 was practical, not sacred: early Unix developers needed a reference point that pre-dated their systems by a comfortable margin, and January 1, 1970 was round enough to work with.

The critical property of Unix time is what it excludes: leap seconds. The POSIX standard defines every day as exactly 86,400 seconds, even though real days occasionally have 86,401 (when a leap second is inserted by international standards bodies). This means Unix time is a linear count, perfect for arithmetic, but it means a Unix timestamp technically represents "civil seconds elapsed" rather than "atomic seconds elapsed." For 99.9% of software use cases, this distinction does not matter.

Seconds vs. Milliseconds: The 10-Digit vs. 13-Digit Divide

One of the most common sources of bugs in timestamp handling is confusing second-precision and millisecond-precision epochs. A second-precision timestamp for mid-2024 looks like 1719100800 — 10 digits. A millisecond-precision timestamp for the same moment is 1719100800000 — 13 digits. Accidentally treating a millisecond timestamp as seconds produces a date in the year 56,968. Accidentally treating a second timestamp as milliseconds gives you sometime in January 1970.

JavaScript's Date.now() returns milliseconds. Python's time.time() returns seconds as a float. Java's System.currentTimeMillis() returns milliseconds. MySQL's UNIX_TIMESTAMP() returns seconds. Redis sorted set scores are floating-point seconds. This inconsistency across ecosystems is why auto-detection based on magnitude (values above 10^12 treated as milliseconds) is a useful heuristic — and why the converter above implements it as the default.

Timezones: The Real Complexity

A Unix timestamp is always UTC — it has no timezone. The timezone only matters when you want to display it to a human. Converting a timestamp to "the time in Kolkata" versus "the time in New York" involves knowing the UTC offset for each timezone at that specific moment in time — not a static offset, because Daylight Saving Time changes offsets twice a year in many regions.

The IANA Timezone Database (maintained at iana.org/time-zones) is the authoritative source for every historical and current DST rule for every named timezone on earth. When your system renders a Unix timestamp in "America/New_York," it consults this database to determine whether that moment falls in Eastern Standard Time (UTC-5) or Eastern Daylight Time (UTC-4). Modern browsers expose this through the Intl.DateTimeFormat API, which is exactly what powers the timezone conversions in this tool — no library needed, no network call, just the JavaScript engine's built-in ICU data.

Named timezones like Asia/Kolkata are far superior to raw offsets like +05:30 for storage purposes. An offset is a snapshot; a named timezone carries the full DST history. If you store an offset today, next year's code reading that offset may mis-render timestamps that straddle a DST boundary.

Converting Back: Human Date to Epoch

The reverse conversion — taking a human-specified date and time in a given timezone and producing a Unix timestamp — is trickier than it sounds because of DST gaps and overlaps. When clocks spring forward, a full hour of wall-clock times simply does not exist (e.g., 2:30 AM never occurs on the day DST begins). When clocks fall back, a full hour of wall-clock times occurs twice. A robust converter must handle these ambiguities, typically by applying the UTC offset computed at the approximate moment and then verifying the result.

The approach used by this tool: estimate the UTC epoch by subtracting the timezone's observed offset from the given local time, then verify the conversion rounds back correctly. For the vast majority of non-ambiguous times this is exact; for the rare DST fold, the earlier of the two valid interpretations is used — consistent with POSIX convention.

The Year 2038 Problem

32-bit signed integers can hold a maximum value of 2,147,483,647. In Unix time, that value corresponds to 03:14:07 UTC on January 19, 2038. Systems that store timestamps in 32-bit signed integers will overflow on this date, either wrapping to a large negative number (representing December 1901) or crashing. This is the "Year 2038 Problem" — the Unix-time analogue of Y2K.

The fix is straightforward: use 64-bit integers. A 64-bit signed Unix timestamp can represent dates up to roughly 292 billion years in the future, comfortably exceeding the expected lifespan of the solar system. Most modern languages and databases already default to 64-bit time storage. MySQL's DATETIME type supports years up to 9999; PostgreSQL's timestamp is 64-bit. The remaining risk is in embedded systems, legacy C code, and 32-bit databases that have not been updated.

Practical Timestamp Patterns in Real Systems

Database schemas: store timestamps as BIGINT (64-bit integer) in milliseconds or as TIMESTAMPTZ (timestamp with timezone, which internally stores UTC). Never store a DATETIME without a timezone context in a multi-region application.

APIs: REST APIs commonly return ISO 8601 strings (2024-06-23T00:00:00Z) or Unix seconds as integers. GraphQL schemas often return ISO strings. When consuming an unfamiliar API, check whether the numeric timestamp field is seconds or milliseconds by comparing to a known current value.

Log analysis: Unix timestamps sort correctly as plain integers, which is why log aggregation systems (Elasticsearch, Loki, Splunk) index them numerically. A range query is just a numeric comparison — no date parsing overhead at query time.

Distributed systems: timestamps from multiple servers can only be meaningfully compared if they reference the same clock source. Network Time Protocol (NTP) synchronizes servers to within milliseconds of UTC. For sub-millisecond accuracy in distributed databases, Google's TrueTime API (used in Spanner) adds bounded uncertainty intervals to account for clock drift.

Reading Timestamps at a Glance

With a little practice you can roughly parse Unix timestamps mentally. The epoch 1,000,000,000 was September 9, 2001. The epoch 1,500,000,000 was July 14, 2017. As of 2024, current timestamps are in the 1.71–1.73 billion range. Every 86,400 increase is one day; every 2,592,000 increase is approximately one month; every 31,536,000 increase is one year. Knowing these anchors lets you quickly sanity-check a timestamp in a log without reaching for a converter.

Unix timestamps are one of computing's genuinely elegant designs: a single integer, universally comparable, timezone-independent, and sortable without any parsing. The complexity they defer to presentation time — timezone conversion, DST handling, human formatting — is real but manageable with the right tools. This converter handles all of it in your browser, instantly.

FAQ

What is the Unix epoch and why does it start on January 1, 1970?
The Unix epoch is the reference point for Unix timestamps: 00:00:00 UTC on January 1, 1970. Early Unix developers chose this date because it was recent enough to be practical (no absurdly large numbers for current dates) and round enough to be memorable. There is nothing scientifically special about 1970 — it was simply a convenient anchor for the operating systems being built at the time.
How do I tell if a Unix timestamp is in seconds or milliseconds?
Check the number of digits. A second-precision Unix timestamp in 2024 has 10 digits (around 1,700,000,000). A millisecond-precision timestamp has 13 digits (around 1,700,000,000,000). Values above 10^12 are almost certainly milliseconds; values below 10^12 are almost certainly seconds. This tool auto-detects based on this rule, but you can override it with the precision toggle.
Does a Unix timestamp include timezone information?
No. A Unix timestamp is always relative to UTC — it has no timezone embedded in it. The timezone only comes into play when you convert the timestamp to a human-readable date for display. The same Unix timestamp represents the same absolute moment everywhere on Earth; it is only the local clock representation that changes by timezone.
What is the Year 2038 problem?
Systems that store Unix timestamps as 32-bit signed integers will overflow on January 19, 2038 at 03:14:07 UTC, because 2,147,483,647 is the maximum value a 32-bit signed integer can hold. After that moment, the counter wraps to a large negative number, representing December 1901. The solution is to use 64-bit integers, which can represent dates billions of years into the future. Most modern software already does this, but legacy embedded systems and old databases may still be at risk.
Why do some timestamps look like 1719100800.000 with decimals?
A decimal Unix timestamp represents sub-second precision expressed as fractional seconds. The integer part counts whole seconds since epoch; the decimal part represents the remaining fraction. For example, .500 means 500 milliseconds past that second. Python's time.time() commonly returns floats in this format. You can multiply by 1000 and take the floor to get the equivalent millisecond-precision integer timestamp.
What is the difference between a Unix timestamp and ISO 8601?
A Unix timestamp is a pure integer (or decimal) count of seconds since 1970-01-01 UTC — compact and sortable numerically, but not human-readable. ISO 8601 is a text format like 2024-06-23T12:00:00Z — human-readable and self-documenting, with timezone information embedded as a suffix (Z for UTC, or ±HH:MM for offsets). Unix timestamps are preferred for internal storage and arithmetic; ISO 8601 strings are preferred for APIs and logs that humans will read.