Unix Timestamp Converter, Convert Epoch to Human Dates and Back

Introduction

A Unix timestamp is a single integer that represents an instant in time as the number of seconds (or milliseconds, depending on the system) that have elapsed since the Unix epoch, 00:00:00 UTC on Thursday, 1 January 1970. The format is universal across POSIX systems, most public APIs, every mainstream database, and a large fraction of log and observability pipelines. It is the lingua franca of machine-readable time on the internet.

This converter translates that integer both ways. Paste a Unix timestamp on the left and read ISO 8601, RFC 2822, a human UTC date, your local time with timezone offset, and a relative phrase like "5 days ago" on the right. Pick a date and time on the right and read the matching Unix epoch in seconds and milliseconds on the left. A live ticker at the top of the tool refreshes every second so you always have a current reference value to copy when writing code, configuring caches, or signing tokens.

The converter auto-detects whether your input is in seconds or milliseconds using a magnitude heuristic: any value whose absolute magnitude is at least 1×10¹¹ is treated as milliseconds; smaller values are treated as seconds. The ten-digit numbers around 1.7 billion that describe dates in 2024 are seconds; thirteen-digit numbers around 1.7 trillion are milliseconds. JavaScript, Java, Python's datetime.now(), and most modern telemetry systems use milliseconds; POSIX, many REST APIs, and most log files use seconds.

Everything runs locally in your browser. No input is sent to a server, nothing is logged, no account is required. The tool is fully responsive and works on phones, tablets, and desktop browsers.

How to Use the Unix Timestamp Converter

1. Paste a Unix timestamp into the top input. The converter accepts both seconds (for example, 1700000000) and milliseconds (for example, 1700000000000) and tells you which unit it detected in the output row labelled "Detected as".
2. Read the decoded representations. The output panel below the input shows ISO 8601 in UTC, RFC 2822 (the format used in HTTP Date headers), a human-readable UTC date, your local time with timezone offset, and a relative phrase such as "5 days ago" or "in 2 hours".
3. Use the "Use now" button to load the current second into the input, or click any preset (Unix epoch 0, Y2K 946684800, 2038 problem 2147483647) to jump to a canonical reference value.
4. Copy any value with the per-row copy button. A green check mark confirms the clipboard write.
5. Convert the other way by picking a date in the lower card's date field and, optionally, a time. The matching Unix epoch in seconds and milliseconds appears immediately below.
6. Watch the live ticker. The "Current Unix time" banner at the top updates every second so you always have a fresh reference value.

The interface has no submit button. Every conversion is reactive: as you type, the output updates instantly. Errors appear in a red panel below the input rather than producing a silent Invalid Date, non-numeric input, empty input, and out-of-range values are all caught before the date object is constructed.

How Unix Time Works

The Unix epoch is a deliberate choice. When Ken Thompson and Dennis Ritchie designed the original Unix time system at Bell Labs in 1971, they picked midnight on 1 January 1970 UTC as the reference point because it was the start of the decade in which Unix was being built. The choice has stuck for fifty-plus years, and almost every modern system anchors its own clock to the same instant.

The epoch

The Unix epoch is 00:00:00 UTC on Thursday, 1 January 1970. Unix timestamps count the number of seconds (or milliseconds) that have elapsed since that instant. Timestamps before the epoch are negative numbers: −1 is one second before the epoch, −86400 is one day before the epoch (midnight on 31 December 1969 UTC). Negative timestamps are uncommon in practice but supported by this tool.

Leap seconds are NOT counted

This is one of the most surprising facts about Unix time. The Earth's rotation is not perfectly uniform, and the international timekeeping community occasionally inserts a "leap second" to keep UTC aligned with solar time. There have been 27 leap seconds since 1972, most recently at the end of 2016. Unix time does not count leap seconds: every UTC day is exactly 86400 Unix seconds, even on leap-second days. When a leap second is inserted, the Unix clock either freezes for a second (the "smear" used by some systems) or simply does not advance through the leap second. UTC ends up one second ahead of Unix time after each leap-second insertion, but the discrepancy is rarely visible to application code.

This tool follows the Unix convention. If you convert a Unix timestamp through a leap-second insertion, you get the Unix-time interpretation, not the civil-time interpretation. For most applications, logging, caching, scheduling, this is exactly what you want.

Seconds vs milliseconds

Unix timestamps come in two precision flavours. POSIX, traditional Unix tooling, and many REST APIs use seconds. JavaScript, Java, Python's datetime.now(), Go's time.Now().UnixMilli(), and most modern observability pipelines use milliseconds. The two units differ by exactly a factor of 1000:

• 1700000000 is a Unix timestamp in seconds → 2023-11-14 22:13:20 UTC.
• 1700000000000 is a Unix timestamp in milliseconds → the same instant.

Other systems use different epoch or different units. Windows FILETIME counts 100-nanosecond ticks since 1601-01-01. .NET DateTime.Ticks follows the same convention. The .NET epoch is sometimes used directly with Unix timestamps through a simple offset arithmetic. macOS uses a similar but slightly different reference. Excel and older Lotus-1-2-3 spreadsheets treat 1900-01-01 as day 1 (with a deliberate Lotus bug for 1900-02-29). For all of those cases, you usually want a dedicated converter rather than this one, but this tool will give you a sensible answer for any number whose magnitude is in the seconds-since-1970 or milliseconds-since-1970 range.

The 2038 problem

Systems that store Unix timestamps as signed 32-bit integers max out at 2,147,483,647, which corresponds to 03:14:07 UTC on Tuesday, 19 January 2038. After that instant, a 32-bit signed integer wraps to its minimum value (−2,147,483,648) and is interpreted as 20:45:52 UTC on Friday, 13 December 1901. The result is a sudden jump backward by about 136 years, which manifests as broken schedules, expired-but-not-really cache entries, and dates from 1901 appearing in 2038+ logs.

This is sometimes called the Y2K38 problem (echoing the Y2K panic around the year 2000). Modern 64-bit operating systems and languages extend the timestamp range to about 292,277,026,596, roughly 292 billion years into the future, well past the heat death of the sun. But embedded firmware, legacy databases, and some industrial control systems still use 32-bit timestamps, and they will need to be patched or replaced before January 2038. The 2038 problem preset in this tool lets you load the exact overflow boundary so you can sanity-check that a system is correctly handling the boundary.

Worked Examples

Example 1, Unix epoch (0)

Input: 0. The converter detects seconds. Output: ISO 8601 1970-01-01T00:00:00.000Z, RFC 2822 Thu, 01 Jan 1970 00:00:00 GMT, Unix (seconds) 0, Unix (milliseconds) 0, relative "in 55 years ago" (or similar, depends on the current date).

Example 2, Billennium (1,000,000,000)

Input: 1000000000. The converter detects seconds. Output: ISO 8601 2001-09-09T01:46:40.000Z, RFC 2822 Sun, 09 Sep 2001 01:46:40 GMT, Unix (seconds) 1000000000, Unix (milliseconds) 1000000000000. The "billennium" is the moment the Unix clock first hit a 10-digit number of seconds, celebrated as a minor milestone in geek culture.

Example 3, Y2K (946684800)

Input: 946684800. Output: ISO 8601 2000-01-01T00:00:00.000Z, RFC 2822 Sat, 01 Jan 2000 00:00:00 GMT. Y2K was the rollover panic around the year 2000; this is the exact Unix timestamp for the first second of the new millennium in UTC.

Example 4, A modern API timestamp (1700000000)

Input: 1700000000. Output: ISO 8601 2023-11-14T22:13:20.000Z, RFC 2822 Tue, 14 Nov 2023 22:13:20 GMT, relative "x days ago" depending on current date. A common pattern in API responses.

Example 5, JavaScript milliseconds (1700000000000)

Input: 1700000000000. The converter detects milliseconds (because |n| ≥ 1×10¹¹) and divides by 1000 internally. Output is identical to Example 4: ISO 8601 2023-11-14T22:13:20.000Z. This is the most common confusion when reading timestamps from JavaScript code, Date.now() returns milliseconds, while most REST APIs return seconds.

Example 6, The 2038 boundary (2147483647)

Input: 2147483647. The converter detects seconds. Output: ISO 8601 2038-01-19T03:14:07.000Z, RFC 2822 Tue, 19 Jan 2038 03:14:07 GMT. This is the largest signed 32-bit integer, and the moment after which 32-bit timestamp systems wrap to negative. Useful for testing whether a system handles the boundary correctly.

Example 7, Date back to Unix timestamp

Input date: 2026-01-01, input time: 00:00:00 (local). Output: Unix (seconds), depends on your browser timezone; for someone in UTC+0 it is 1767225600; for someone in UTC−05:00 (Eastern) it is 1767200400. The converter uses the browser's local timezone because that is what most users expect when typing "when did this happen", to get a UTC-specific epoch, append the Z suffix in the upper field.

Where Unix Timestamps Show Up

Logs

Server logs almost universally use Unix timestamps. Apache, nginx, journald, syslog, AWS CloudWatch, Google Cloud Logging, and Datadog all write timestamps as integers rather than formatted strings. The advantage is timezone independence: every log line is anchored to the same instant regardless of where the server runs. The disadvantage is readability for humans, which is exactly why tools like this converter exist.

JWT exp and iat

JSON Web Tokens carry two timestamp claims in their payload. iat (issued at) records when the token was minted; exp (expiration time) records when it stops being valid. Both are Unix seconds, not milliseconds. When you debug an "expired token" error, decoding the exp claim through this converter is usually the fastest way to see whether the server clock is off, the client clock is off, or the token's exp value was set wrong.

Databases

Most relational and NoSQL databases store timestamps as Unix seconds or milliseconds. MySQL's UNIX_TIMESTAMP() returns seconds. PostgreSQL's EXTRACT(EPOCH FROM NOW()) returns seconds. SQLite has no native timestamp type but stores them as Unix seconds in practice. MongoDB stores BSON dates as 64-bit milliseconds since the epoch. The exact unit varies by database and column type; the magnitude heuristic in this converter handles them all.

APIs

REST and GraphQL APIs almost always return timestamps in their JSON payloads. Some use seconds, some use milliseconds, some use ISO 8601 strings. Reading API documentation carefully is the only reliable way to know which, but this converter's auto-detection lets you paste the value and read the result without thinking about it.

Cron

Cron schedules describe "when to run a job" in local time, but the resulting job execution logs almost always record the run time as a Unix timestamp. Cron daemons like vixie-cron and cronie have no concept of timezones inside the schedule itself; they use the host system's timezone. Converting between cron expressions and Unix timestamps is a separate problem (and a different tool) but the decoded Unix timestamps appear in the resulting execution logs.

Common Mistakes to Avoid

Confusing seconds with milliseconds

The single most common mistake. A value of 1700000000 means November 14, 2023. A value of 1700000000000 means the same instant, but if you misread the first as milliseconds and the second as seconds, you are off by about 55 years. Always check the magnitude. This converter flags which unit it detected in the row labelled "Detected as".

Assuming a timezone that is not there

Unix timestamps are always anchored to UTC. They have no timezone of their own, the timezone is only applied when you render the timestamp as a human-readable string. If you see 1700000000 in a database and interpret it as "5:13 PM Eastern", you are wrong: the timestamp is 22:13:20 UTC, which is 5:13 PM Eastern only in the standard time zone, and 4:13 PM in Eastern Daylight Time. This converter shows UTC by default and your local time separately, so you can see both at once.

Forgetting leap seconds

If you are doing precise calendar arithmetic, remember that Unix time does not count leap seconds. The day on which a leap second is inserted is 86401 seconds long in UTC but 86400 seconds long in Unix time. After the leap second, UTC is 1 second ahead of the Unix clock. This almost never matters for application code; it matters if you are comparing Unix timestamps to TAI (International Atomic Time) or to historical astronomical observations.

Misunderstanding the 2038 boundary

If your system stores timestamps as signed 32-bit integers, the boundary is 03:14:07 UTC on 19 January 2038, not midnight on 1 January 2038, not the Unix timestamp 2147483647 plus one. The exact instant is 2147483647 seconds after the epoch. If you are auditing a system for Y2K38 readiness, set the system clock to 2147483647 (or thereabouts) and watch for any date-handling code that overflows.

Using Date.parse() with locale-dependent strings

JavaScript's Date.parse() is famously implementation-defined for non-ISO strings. Always pass an ISO 8601 string or a Unix timestamp integer to Date.parse(); do not pass "01/02/2026" because that is interpreted as January 2 in the United States and February 1 in much of Europe. This converter always works with unambiguous numeric inputs.

Frequently Asked Questions

What is a Unix timestamp? A Unix timestamp is the number of seconds that have elapsed since the Unix epoch, 00:00:00 UTC on Thursday, 1 January 1970, not counting leap seconds. It is the standard machine-readable time representation in POSIX systems, most databases, and most public APIs. JavaScript and some other ecosystems use milliseconds rather than seconds; the magnitude is the only difference between the two.

Why do some APIs give milliseconds instead of seconds? Milliseconds give sub-second precision, which matters for high-frequency trading systems, observability metrics, event ordering in distributed systems, and any application where the order of events that happen in the same second needs to be unambiguous. JavaScript, Java, Python's datetime.now(), Go's time.Now().UnixMilli(), and most modern telemetry pipelines use milliseconds because the per-call overhead of converting to seconds is negligible and the precision is often useful.

What is the 2038 problem? Systems that store Unix timestamps as signed 32-bit integers overflow at 2,147,483,647, 03:14:07 UTC on 19 January 2038. After that moment the value wraps to negative and is interpreted as 20 December 1901 (and a few seconds later). Modern 64-bit systems extend the range to about year 292,277,026,596, but embedded firmware, legacy databases, and some industrial control systems still use 32-bit timestamps and will need to be patched or replaced before January 2038.

Why does the converter show a different time in local vs UTC? Unix timestamps are anchored to UTC. When you read the same timestamp in your local timezone, the rendered time shifts by the offset between your timezone and UTC. For someone in New York (UTC−05:00 in standard time, UTC−04:00 in daylight saving time), 1700000000 reads as 17:13:20 rather than 22:13:20. This is normal and expected: the underlying instant is the same; only the rendering changes. If you want UTC specifically, use the "Human (UTC)" row.

How do I convert a Unix timestamp in Python? datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc) returns a UTC-aware datetime. For a naive UTC datetime, use datetime.datetime.utcfromtimestamp(1700000000) (deprecated in Python 3.12 but still functional). For milliseconds, divide by 1000 first: datetime.datetime.fromtimestamp(1700000000000 / 1000, tz=datetime.timezone.utc). Modern code should prefer the timezone-aware form to avoid silent bugs around daylight saving.

How do I convert a Unix timestamp in JavaScript? new Date(1700000000 * 1000) returns a Date object representing the same instant, because JavaScript's Date constructor expects milliseconds. Equivalently, new Date(1700000000000) works directly on a millisecond value. To get the current time as a Unix timestamp in seconds, use Math.floor(Date.now() / 1000). The * 1000 conversion is the most common source of bugs in JavaScript date handling.

Is this converter safe for sensitive data? Yes. Every conversion runs locally in your browser, no input is sent to a server, no analytics are recorded, no cookies are set. The page can be loaded over HTTPS, but the actual computation does not touch the network after the initial page load. You can verify this by opening your browser's developer tools, switching to the Network tab, and using the converter: no outbound requests appear.

References

• POSIX.1-2017 §4.16 Seconds Since the Epoch, the IEEE / The Open Group standard that defines Unix time as "seconds since the epoch", excluding leap seconds.
• RFC 3339, Date and Time on the Internet: Timestamps (Klyne & Newman, 2002), the strict internet profile of ISO 8601, used in HTTP, email, and most public APIs.
• ISO 8601:2019, Date and time, Representations for information interchange, the international standard for date and time format strings.
• IANA Time Zone Database (tzdata), the canonical source of timezone definitions used by essentially every operating system. Updated several times a year as jurisdictions change their DST rules.
• ECMAScript 2024 §21.4 Date Time String Format, the specification JavaScript engines follow when parsing ISO 8601 strings and constructing Date objects.