Unix Timestamp Converter

This free Unix timestamp converter turns epoch timestamps into human-readable dates and back again, instantly and entirely in your browser. It shows the current Unix time as a live clock, converts any timestamp you paste into both your local time and UTC, and lets you pick a date and get its timestamp in return. It handles both seconds and milliseconds automatically. Below the tool is a complete guide to what a Unix timestamp is, why it exists, how time zones and the famous Year 2038 problem fit in, and how to work with epoch time correctly in your own code.

What is a Unix timestamp?

A Unix timestamp, also called epoch time or POSIX time, is a single number that represents a moment in time as the count of seconds that have elapsed since a fixed reference point. That reference point, known as the Unix epoch, is midnight UTC on January 1, 1970. So a timestamp of zero is that exact instant, a timestamp of 60 is one minute later, and the number you see in the live clock above is how many seconds have passed since then up to right now.

The appeal of this representation is its simplicity. A date and time expressed in the usual human way involves a year, a month, a day, an hour, a minute, a second, and a time zone, all interacting through irregular rules about month lengths, leap years, and daylight saving. A Unix timestamp collapses all of that into one plain integer. Two moments can be compared just by comparing two numbers, and the difference between them in seconds is simply their subtraction. This makes epoch time the natural way for computers to store and reason about time.

Why epoch time starts in 1970

The choice of January 1, 1970 is a piece of computing history. When the Unix operating system was being developed at the start of the 1970s, its designers needed a convenient zero point for measuring time, and the beginning of that decade was a clean, recent, round choice. It was close enough to the present that the numbers would stay manageable, and far enough back to cover the dates the systems of the era cared about. The convention stuck, spread far beyond Unix, and is now used across virtually every operating system, programming language, database, and web API in existence.

Because the epoch is defined in UTC, a Unix timestamp is inherently time-zone-neutral. The same instant has the same timestamp everywhere on Earth. It is only when you convert that number into a readable date that a time zone enters the picture, which is exactly why the tool above shows you both your local interpretation and the UTC interpretation of any timestamp side by side.

Seconds versus milliseconds

One of the most common sources of confusion with timestamps is the unit. The classic Unix timestamp counts whole seconds, which is what you see in most databases, in the JWT exp and iat claims, and in many APIs. But several environments, JavaScript most notably, count milliseconds since the epoch instead, producing a number that is a thousand times larger. A seconds timestamp for a recent date has ten digits, while the millisecond equivalent has thirteen.

Mixing the two units is a frequent bug. If you feed a seconds value into something expecting milliseconds, you get a date in 1970, because the number is interpreted as a tiny fraction of the intended time. If you feed milliseconds into something expecting seconds, you get a date thousands of years in the future. The converter above detects the likely unit from the magnitude of the number and shows the interpretation, so you can immediately spot if you are dealing with the wrong scale.

How time zones affect the conversion

A timestamp itself carries no time zone, but the readable date you derive from it absolutely does. The same timestamp shown in Tokyo and in New York describes the same instant but displays as different wall-clock times, because those cities are at different offsets from UTC. This is why a timestamp converter must always be clear about which zone it is rendering, and why the tool above lets you switch between your local time and UTC.

UTC, Coordinated Universal Time, is the global reference against which all time zones are defined as offsets. Storing and transmitting time as a Unix timestamp, which is UTC-based, sidesteps an enormous amount of complexity, because the conversion to a local display happens only at the very edge, when a human needs to read it. The strong recommendation in almost every system is to store time as UTC-based timestamps and convert to local time only for display, never the other way around.

Daylight saving time and other complications

Local time is messier than it first appears, and Unix timestamps are valued precisely because they avoid the mess. Many regions shift their clocks forward and back for daylight saving time, which means local time is not a smooth, continuous line: an hour can repeat in autumn and vanish in spring. Some regions have changed their daylight saving rules over the years, and a few have changed their base offset entirely. Local calendars also differ in subtle ways across history.

A Unix timestamp is immune to all of this because it measures a steady count of seconds in UTC, with no clock-shifting and no regional rules. The complications only reappear at the moment of display, when the timestamp is rendered into a particular zone’s local time. By keeping the stored value as a clean epoch number and deferring the local rendering, systems avoid an entire category of bugs that arise from doing arithmetic on local times across daylight saving boundaries.

The Year 2038 problem

The Year 2038 problem is the timestamp world’s version of the Year 2000 concern, and it is worth understanding. Many older systems store the Unix timestamp in a signed 32-bit integer. A signed 32-bit integer can hold values up to about 2.1 billion, and the timestamp will reach that ceiling at 03:14:07 UTC on January 19, 2038. One second later, the value overflows and wraps around to a large negative number, which such systems interpret as a date back in 1901.

The fix is to store timestamps in 64-bit integers, which push the overflow point billions of years into the future, far beyond any practical concern. Most modern systems and languages have already moved to 64-bit time, so the problem is largely contained, but it still lurks in old hardware, embedded devices, and legacy software that has not been updated. It is a useful reminder that the simple-looking integer behind a timestamp has real limits determined by how many bits are used to store it.

Working with timestamps in code

Every major language can produce and parse Unix timestamps, and knowing the basic idioms saves a lot of searching. The key thing to watch, again, is the seconds-versus-milliseconds distinction.

JavaScript

JavaScript works in milliseconds. Date.now() gives the current time in milliseconds, so dividing by 1000 and flooring yields a seconds timestamp. new Date(ms) turns a millisecond value back into a date object, so a seconds timestamp must be multiplied by 1000 first.

const seconds = Math.floor(Date.now() / 1000);
const date = new Date(seconds * 1000);

Python

Python’s time.time() returns the current epoch time in seconds as a floating point number. The datetime module converts in both directions, and it is good practice to be explicit about UTC to avoid local-time surprises.

SQL databases

Databases vary. Some store native timestamp types, others store epoch integers directly, and most provide functions to convert between an epoch value and a readable timestamp. When a column holds a raw integer, this converter is a quick way to sanity-check what a stored value actually represents.

Where you will meet Unix timestamps

Epoch time is everywhere once you start looking. API responses routinely express creation and modification times as timestamps. Log files stamp each entry with epoch time for precise, sortable ordering. The JWT decoder shows that authentication tokens carry their issue and expiry times as Unix timestamps, which is exactly why a decoder needs to convert them to be readable. When an API hands you a large JSON document full of timestamp fields, the JSON formatter helps you read the structure while this converter helps you read the times inside it. Caches, cookies, rate limiters, and scheduling systems all lean on epoch time for the same reason: it is the simplest reliable way to mark and compare moments.

How to use this timestamp converter

The live clock at the top counts the current Unix time in seconds and updates every second, with a copy button for grabbing the value. To convert a timestamp to a date, paste it into the first field, or click Use now to drop in the current time; the tool shows the result in both your local time and UTC, and indicates whether it read the input as seconds or milliseconds. To go the other way, pick a date and time in the second field and the corresponding Unix timestamp appears immediately. Use the zone selector in the header to control how dates are displayed. Everything runs locally, so you can convert sensitive timestamps without anything leaving your browser.

Unix time versus ISO 8601

If a Unix timestamp is the format computers prefer, ISO 8601 is the format that bridges machines and humans. It is the international standard for writing dates and times as text, in the form 2024-05-18T07:00:00Z, where the date and time are laid out in a fixed, unambiguous order and the trailing Z means UTC. The tool above shows the ISO 8601 form alongside the timestamp because the two are complementary: the epoch number is compact and easy to compute with, while the ISO string is self-describing and readable at a glance.

The advantage of ISO 8601 over the many regional date formats is that it removes ambiguity. A date written as 05/06/2024 could be the fifth of June or the sixth of May depending on the country, but 2024-06-05 can only mean one thing, and because the components run from largest to smallest, ISO strings even sort correctly as plain text. The general guidance is to store and compute with Unix timestamps internally, exchange times between systems as ISO 8601 strings when a readable text format is needed, and only convert to a local, human-friendly format at the final point of display.

Leap seconds and the limits of precision

There is a subtle wrinkle in how Unix time relates to the actual rotation of the Earth, and it is worth knowing even though it rarely matters in everyday work. Occasionally a leap second is added to civil time to keep our clocks aligned with the planet’s slightly irregular spin. Unix time, however, is defined to ignore leap seconds: it simply counts as though every day has exactly 86,400 seconds. This keeps the arithmetic clean, since you can always convert between days and seconds with a fixed multiplier, but it means Unix time is not a perfectly continuous count of physical seconds across a leap second event.

For virtually all applications, including everything this converter is used for, that distinction has no practical consequence. It only becomes relevant in systems that demand sub-second precision over long spans, such as certain scientific or financial timing applications, which use specialized time scales instead. For ordinary web, app, and database work, treating Unix time as a clean count of 86,400 seconds per day is exactly right, and it is what makes epoch time so convenient.

A practical debugging walkthrough

Timestamps are a frequent source of mysterious bugs, and a calm, systematic approach resolves most of them quickly. Imagine an API returns a field that should be a recent event time, but your code displays it as a date in early 1970. Pasting the raw value into the converter above immediately reveals the problem: the value is in seconds, but your code treated it as milliseconds, so dividing instead of multiplying by 1000 produced a near-zero millisecond value just after the epoch. The fix is to multiply the seconds value by 1000 before constructing the date.

The reverse mistake produces a date far in the future. If a value displays as a year in the tens of thousands, you have fed a millisecond value into something expecting seconds. Again, the converter tells you which unit a number most likely is by its number of digits, so a quick paste settles the question before you change any code. A third common case is a time that is off by a fixed number of hours, which almost always means a time zone was applied where UTC was intended, or vice versa; switching the zone selector in the tool confirms whether the underlying timestamp is correct and only the display zone is wrong.

The general discipline that prevents these bugs is to decide on one canonical representation, almost always Unix seconds in UTC, store and pass that everywhere internally, and convert to other units or zones only at the boundaries where data enters from or leaves to the outside world. When every conversion happens at a known edge rather than scattered through the code, a wrong date becomes easy to trace back to the single boundary that mishandled it.

Why store timestamps instead of formatted dates

A reasonable question is why systems bother with an opaque number at all when they could just store a readable date string like “June 5, 2024 at 3:00 PM.” The answer comes down to reliability and computation. A formatted date string is ambiguous and fragile: it depends on a locale, a time zone, and a format convention, any of which can be misread or lost as data moves between systems. Two services that format dates differently can disagree about what the same string means, and sorting or comparing such strings is error-prone.

A Unix timestamp has none of these weaknesses. It is a single canonical number with one unambiguous meaning, it sorts and compares correctly with plain numeric operations, and the difference between two timestamps is simply their subtraction, giving an exact duration in seconds with no calendar arithmetic. Storage is compact, indexing in a database is efficient, and there is no locale or format to get wrong. The readable form is generated only when a human needs to see it, which is a cheap, well-defined operation. This is why the overwhelming convention in software is to store the timestamp and format on demand, rather than store the formatted text and try to parse it back.

The same logic explains why so many of the other formats developers work with lean on epoch time underneath. A token’s expiry, a log entry’s order, a cache’s freshness, and a scheduled job’s trigger time are all most naturally expressed as a number to compare against the current timestamp. Comparing “is now past this moment” becomes a trivial numeric check rather than a date-parsing exercise, which is both faster and far less likely to harbor a bug.

Timestamp formats across common systems

Different environments expose epoch time in slightly different ways, and a quick reference helps when you move between them. The crucial detail in every case remains the unit, seconds or milliseconds.

The pattern to notice is that there is no single universal unit, which is exactly why the seconds-versus-milliseconds question comes up so often when systems talk to one another. A JavaScript front end working in milliseconds that exchanges times with a Python or PHP back end working in seconds must convert at the boundary between them, or one side will be off by a factor of a thousand. Keeping a clear note of which unit each system uses, and converting deliberately at each handoff, removes the single most common timestamp bug. The converter above is a fast way to confirm, for any given number, which unit and therefore which moment you are actually looking at.

One final tip when reading raw values: a current timestamp in seconds is a ten-digit number, and it will remain ten digits until the year 2286, so for any date you are likely to handle today, ten digits means seconds and thirteen means milliseconds. That single heuristic resolves the majority of timestamp confusion at a glance, and it is built into how this tool interprets whatever you paste in.

Frequently asked questions