Timestamp converter

Unix time — also called epoch time or a unix timestamp — is a way of representing a specific point in time as a single number: the count of seconds that have elapsed since the unix epoch, which is 00:00:00 UTC on January 1, 1970. Instead of storing a date as a string like “July 14, 2026, 3:42 PM,” a computer stores it as a number such as 1783007520. That single integer is unambiguous, timezone-independent, and trivially easy to compare, sort, and do math on — which is exactly why almost every programming language, database, and API uses it internally.

The name comes from the Unix operating system, where this convention originated in the early 1970s, but it is now a universal standard used everywhere from JavaScript's Date object to Python's datetime module, SQL databases, JWTs, log files, and REST APIs. When you see a field called created_at, exp, or timestamp that's just a large number, it is almost always a unix timestamp.

A timestamp is always relative to UTC, not any particular timezone — the number itself never changes no matter where in the world you are. What changes is how you choose to display it. That's the core job of a converter like this one: take the raw number and render it as a readable date in whatever timezone you care about.

The single biggest source of unix-timestamp bugs is unit confusion: treating a millisecond timestamp as seconds (or vice versa) silently produces a date that is off by a factor of 1,000 — usually landing somewhere in 1970 or the far future. There is no header or type that tells you which unit a raw number uses, so tools and developers rely on a simple heuristic: digit count.

This tool applies exactly that heuristic: 10 digits or fewer is read as seconds, 11–13 digits as milliseconds, and anything longer as microseconds, with a badge showing which unit was detected so you can sanity-check it. If your value looks off by 1,000x or a million x, the unit was almost certainly misidentified upstream — check the source system's documentation.

Many older systems store unix timestamps as a signed 32-bit integer. A signed 32-bit integer can only hold values up to 2,147,483,647 — and the unix timestamp will reach exactly that number at 03:14:07 UTC on January 19, 2038. One second later, the value overflows and wraps around to a large negative number, which many systems will interpret as a date in December 1901. This is known as the Year 2038 problem (sometimes “Y2038” or “the Epochalypse”), and it is a direct sibling of the more famous Y2K bug.

Modern 64-bit systems sidestep the problem entirely — a signed 64-bit timestamp doesn't overflow for roughly another 292 billion years — and most current operating systems, databases, and languages have already migrated to 64-bit time representations. The risk remains in embedded systems, older 32-bit hardware, legacy file formats, and databases with 32-bit date/time columns that haven't been upgraded. If you work on infrastructure with a multi-decade lifespan (industrial control systems, firmware, long-lived file formats), it's worth explicitly checking whether your timestamp fields are 32-bit or 64-bit.

A unix timestamp is always a count of seconds since the epoch in UTC (Coordinated Universal Time) — it has no timezone attached to it, because it doesn't need one. The number 1783007520 refers to the exact same instant everywhere on Earth, whether you're in Karachi, London, or Los Angeles. Timezone only enters the picture when you convert that number into a human-readable calendar date and clock time, because “what year, month, day, and hour is it” genuinely depends on where you are standing.

This is why storing timestamps (or any UTC-based datetime) is the right default for backend systems, databases, and APIs: it eliminates an entire category of bugs around daylight saving time transitions, server timezone misconfiguration, and ambiguous local times. You only convert to a specific timezone at the very last step, when displaying the value to a human. This tool follows that same pattern — it shows you both the UTC value (ISO 8601 format, unambiguous) and your browser's detected local timezone side by side, using the Intl.DateTimeFormat API to read your actual system timezone rather than guessing.

One subtlety worth knowing: daylight saving time (DST) means the same UTC instant can map to different UTC offsets in the same timezone depending on the time of year (e.g. America/New_York is UTC-5 in winter and UTC-4 in summer). A correct converter — including this one — resolves that automatically based on the actual date, not a fixed offset.

Getting “right now” as a unix timestamp is one of the most common one-liners in programming. Here's how to do it in the languages you'll run into most often:

Converting back to a date is just as common. In JavaScript, new Date(unixSeconds * 1000) gives you a Date object; in Python, datetime.fromtimestamp(unix_seconds); in PHP, date('Y-m-d H:i:s', $unixSeconds); and in SQL, TO_TIMESTAMP(unix_seconds) (Postgres) or FROM_UNIXTIME(unix_seconds) (MySQL). Always double-check whether the function you are calling expects seconds or milliseconds — that mismatch is, again, the most common bug in this whole space.

• Debugging APIs and logs. Server logs, webhook payloads, and API responses are full of raw unix timestamps. Pasting one in here instantly tells you what actually happened and when.
• Reading JWTs. JSON Web Tokens encode iat (issued at) and exp (expiry) as unix seconds — converting them tells you exactly when a token was minted or will expire.
• Database work. Many schemas store created_at or updated_at as integers rather than native datetime columns, especially in NoSQL stores and event logs.
• Scheduling and cron jobs. Cron next-run calculations and job queues frequently pass around unix time internally — pair this with our cron expression generator when you need to go the other direction.
• QA and testing. Generating a specific past or future timestamp to test expiry logic, trial periods, or time-based feature flags.
• Blockchain and crypto. Block timestamps, transaction times, and smart contract events are almost always raw unix seconds.

Unix timestamps aren't the only way to represent a point in time, and it helps to know how they relate to the alternatives you'll run into. ISO 8601 (e.g. 2026-07-14T15:42:00Z) is a human-readable, sortable string format that's become the standard for APIs and logs where readability matters — it encodes the same instant as a unix timestamp but keeps the year, month, day, and time explicit, which makes it easier to eyeball and safer to log. RFC 2822 (e.g. Fri, 14 Jul 2026 15:42:00 +0000) shows up mostly in email headers and older HTTP date fields. Excel/spreadsheet serial dates count days (not seconds) since December 30, 1899, which is why a spreadsheet import can produce wildly wrong dates if it's mistaken for a unix timestamp — always check whether a suspiciously small or large number is meant to be days or seconds before converting it.

Unix time wins for machine-to-machine communication because it's a plain integer: cheap to store, cheap to compare, and immune to string-parsing ambiguity (is 03/04/2026 March 4th or April 3rd? A timestamp never has that problem). ISO 8601 wins when a human — or a log-scanning engineer at 2 a.m. — needs to read the value directly. Good systems often store both: a unix timestamp (or a native datetime column) for computation, and render ISO 8601 in anything meant for human eyes.

Everything on this page runs client-side using the browser's built-in Date and Intl APIs — there is no server round-trip, so conversions update instantly as you type and nothing you enter ever leaves your device. The “current unix time” clock reads Date.now() on an interval and re-renders every second; because that value depends on when the page loaded, it's deferred to a useEffect hook so the server-rendered HTML and the first client render always match (avoiding React hydration warnings).

The unix-to-date converter first strips non-digit characters to count digits, classifies the value as seconds, milliseconds, or microseconds using the ranges described above, then normalizes everything to milliseconds internally (the unit JavaScript's Date constructor expects) before rendering the local time, UTC string, relative time, and day of week. The relative-time string (“3 days ago,” “in 2 hours”) is produced with Intl.RelativeTimeFormat, which automatically picks the most natural unit and correct grammar for the size of the gap. The date-to-unix converter reads a datetime-local input, which has no timezone of its own, and interprets it either as your browser's local timezone (via the standard Date constructor) or as UTC (via Date.UTC), depending on which mode you select.

• Always check the digit count before trusting a value — 10 digits means seconds, 13 means milliseconds.
• Store and transmit timestamps in UTC; only convert to a local timezone for display, at the last possible moment.
• Prefer ISO 8601 strings (e.g. 2026-07-14T15:42:00Z) over raw numbers in logs and APIs meant for humans to read — they're self-describing and sort correctly as text.
• Negative timestamps are valid and represent dates before January 1, 1970.
• Watch for off-by-1000 errors when a function unexpectedly returns seconds where you expected milliseconds, or vice versa — this is the single most common timestamp bug.

• Mixing seconds and milliseconds. Passing a seconds timestamp into a function that expects milliseconds (or the reverse) is the single most common bug. In JavaScript specifically, new Date(unixSeconds) without multiplying by 1000 will produce a date sometime in 1970, because Date always expects milliseconds.
• Assuming a fixed UTC offset. Hardcoding “UTC-5” for a timezone that observes daylight saving time will be wrong for half the year. Always use a timezone-aware library or the Intl API, which resolves the correct offset for the specific date in question.
• Truncating instead of rounding. When converting milliseconds to seconds, using Math.floor vs. Math.round can shift a boundary timestamp by a second, which occasionally matters for exact-match comparisons in tests or caching keys.
• Forgetting timestamps can be negative. Dates before 1970 are valid unix timestamps — they're just negative numbers. Code that assumes timestamps are always positive (e.g. using an unsigned integer type) will break on historical dates.
• Losing precision in JSON or Excel. Very large microsecond or nanosecond timestamps can exceed the safe integer range in JavaScript (Number.MAX_SAFE_INTEGER) or get silently rounded by spreadsheet software — treat them as strings if exact precision matters downstream.