Convert Unix timestamp to a human-readable date, a date to Unix time, or plain text like "tomorrow" or "next Monday" — with relative time, copyable results, and a live current-timestamp display.
Supports: today, tomorrow, yesterday, "next Monday" / "last Friday", "in 3 days" / "in 2 weeks" / "in 5 hours", "3 days ago", and standard dates like "July 22, 2026" or "2026-07-22".
| Human Date | Unix Timestamp |
|---|
Click any row to load it into the converter above.
A Unix timestamp — also called epoch time — counts the number of seconds that have elapsed since midnight UTC on January 1, 1970 (the "Unix epoch"). Instead of storing a date as a string like "22 July 2026," computers often store it as a single number, such as 1753142400, which is compact, unambiguous, and easy to compare or sort.
The choice of January 1, 1970 as the reference point wasn't arbitrary significance — it was simply a convenient round date chosen by early Unix developers when the system was being designed in the early 1970s, and it stuck as the de facto standard across virtually every operating system, programming language, and database that followed.
Because a Unix timestamp is timezone-independent, it avoids the classic bugs that come from storing dates as local time strings. Two servers in different countries can agree on exactly the same instant just by comparing the same number — no timezone conversion needed until it's time to display the date to a user.
The original Unix standard uses seconds, which is still common in most backend systems, log files, and APIs. JavaScript's built-in Date.now() and many modern web frameworks use milliseconds instead, for sub-second precision. Mixing up the two is one of the most common timestamp bugs — a millisecond value fed into a seconds-based system lands you somewhere in the year 48000, or, going the other way, in 1970.
Systems that store Unix time as a signed 32-bit integer will overflow on 19 January 2038, wrapping back to 1901 — a limitation known as the Year 2038 problem. Most modern 64-bit systems have already moved past this limit, but some embedded and legacy systems remain at risk.
created_at or updated_at fields stored as epoch integers.Every major programming language and database offers a built-in way to read the current Unix time, though the exact unit (seconds vs milliseconds) and function name differ. This is a common source of off-by-1000 bugs when code moves between languages or between frontend and backend, so it helps to know the default for each.
Date.now() returns the current time in milliseconds since epoch. To get seconds, divide by 1000 and round down: Math.floor(Date.now() / 1000). The older new Date().getTime() does the same thing as Date.now(), just less directly.
time.time() from the built-in time module returns seconds since epoch as a float, including sub-second precision. int(time.time()) rounds it down to a whole-second integer, matching the classic Unix format used by most APIs and log files.
time() returns the current Unix timestamp in seconds as an integer — this has been PHP's default since its earliest versions and hasn't changed. For millisecond precision, PHP uses microtime(true) instead, which returns a float.
UNIX_TIMESTAMP() in MySQL returns the current time in seconds since epoch, and the same function can convert a stored DATETIME column into its Unix equivalent. PostgreSQL uses EXTRACT(EPOCH FROM NOW()) for the same purpose.
Spreadsheets don't store dates as Unix time natively — they use a serial day count from a different reference date. To convert a spreadsheet date to a Unix timestamp, the common formula is =(A1-DATE(1970,1,1))*86400, which measures the difference in days from the Unix epoch and multiplies by the number of seconds in a day.
Unix time isn't the only standard way to represent a moment in time — it's just the most compact. Depending on the system you're working with, you may encounter one of a few common alternatives, each suited to a different purpose.
The format this tool shows as "ISO 8601" (e.g. 2026-07-22T10:30:00.000Z) is a human-readable, sortable string standard widely used in JSON APIs, log files, and international data exchange. Unlike a raw Unix timestamp, it's readable at a glance and unambiguous about which calendar date and time zone it refers to.
Older systems, particularly email headers, use RFC 2822 format (e.g. Wed, 22 Jul 2026 10:30:00 GMT). It's more verbose than ISO 8601 but still widely supported by date-parsing libraries across most languages.
Even though ISO 8601 is easier to read, Unix timestamps remain the preferred internal storage format for most systems because comparing two integers is faster and simpler than parsing and comparing two date strings — especially at scale, across millions of database rows.
Unix timestamps can be negative — this simply represents a moment before the epoch. For example, a timestamp of -86400 corresponds to December 31, 1969. Most modern libraries handle negative Unix time correctly, but some older or embedded systems that use unsigned integers cannot represent dates before 1970 at all.
India Standard Time is a fixed offset of UTC+5:30, with no daylight saving adjustments throughout the year. This means converting a Unix timestamp (always UTC-based internally) to IST is a simple, constant addition of 5 hours 30 minutes — unlike countries that observe daylight saving, where the same timestamp can map to different local times depending on the season. This tool automatically shows your browser's local time zone alongside UTC, so if you're in India it will display the IST-equivalent time directly.
Unix time officially ignores leap seconds — the occasional extra second added to UTC to keep it aligned with Earth's rotation. In practice, this means Unix timestamps are not a perfectly uniform count of physical seconds since 1970, though for almost all everyday and application purposes this discrepancy (currently under a minute total) is irrelevant.
It's the number of seconds elapsed since midnight UTC on January 1, 1970, ignoring leap seconds — a compact, timezone-independent way for computers to record a point in time.
It updates every second and is shown live at the top of this page, in both seconds and milliseconds.
The Unix standard uses seconds, but JavaScript's Date object and many web APIs use milliseconds for finer precision. This tool supports both — just toggle the unit before converting.
A Unix timestamp itself has no timezone — it's an absolute point in time. This tool shows the equivalent date in both UTC and your browser's local time zone.
Systems storing Unix time as a signed 32-bit integer will overflow on 19 January 2038 — the Year 2038 problem. Modern 64-bit systems are unaffected.
In Python, use int(time.time()). In JavaScript, use Math.floor(Date.now() / 1000). Both return the current time in whole seconds since the Unix epoch.
Yes — a negative value simply represents a date before January 1, 1970. Most modern systems handle this correctly, though some older or embedded systems using unsigned integers cannot.
India Standard Time is a constant UTC+5:30 year-round, with no daylight saving changes, making conversion from a UTC-based Unix timestamp to IST a simple fixed addition.
This almost always means a time zone mismatch — the timestamp was generated in one time zone (often UTC) and displayed as if it were local time, or vice versa. Always check whether the source system stores UTC or local time before converting.
Unix time is based on UTC, which is very close to GMT for practical purposes (GMT is technically a time zone, UTC a time standard). The two are interchangeable in almost all everyday contexts, including this converter.
Timestamp-related bugs are among the most frequent — and most confusing — issues developers run into, largely because a wrong value still looks like a valid date, just the wrong one. A few patterns show up again and again.
If a date converter suddenly shows "January 1, 1970" or a date very close to it, the most likely cause is that a value of 0, null, or an empty string was accidentally passed in as the timestamp instead of a real value — this is often the first sign of a missing or failed database field.
A date that jumps to the year 48000 or similar is almost always a units mismatch — a millisecond value was fed into a function expecting seconds, so it was multiplied by 1000 more than it should have been. Multiplying (or dividing) by exactly 1000 is the fix in most cases.
When a date is consistently one day earlier or later than expected, especially right around midnight, the cause is nearly always a time zone conversion issue — a UTC timestamp was displayed using local formatting rules without converting the underlying time zone first, or the reverse.
Whenever a date looks suspicious in an API response, log file, or database record, pasting the raw timestamp into a converter like this one — checking both the UTC and local readings — is usually the fastest way to confirm whether the value itself is wrong or whether it's just being displayed incorrectly.
While this tool is built for developers, the underlying need — turning a raw number into a date people understand, or the reverse — comes up across several kinds of work.
Reading through request logs, database exports, or third-party API payloads that return epoch time instead of formatted dates is a near-daily task for anyone working on server-side code, especially when debugging why a record was created or updated at an unexpected time.
When investigating a bug report tied to "something that happened around 3pm yesterday," support and QA staff often need to convert a human description of time into a timestamp to search logs, or convert a log's raw timestamp back into something they can describe to a user.
Spreadsheets, exported CSVs, and analytics dashboards frequently store event times as epoch integers for compactness. Analysts converting these into readable dates for reports, or the other way around when filtering a dataset to a specific time window, benefit from a quick, reliable converter rather than writing one-off script code for each check.
Devices with limited storage and processing power commonly log events as raw Unix timestamps to save space, making a converter essential when reviewing device logs pulled from sensors, cameras, or industrial equipment during troubleshooting.