Convertor de timestamp Unix

Convert Unix timestamps to dates — and back — instantly

This Unix timestamp converter turns any epoch time into a human-readable date and converts any date back into a timestamp, entirely in your browser. A live ticker shows the current Unix time ticking in both seconds and milliseconds so you always have a fresh epoch to copy. No sign-up, no server, nothing uploaded.

Paste any number and the tool auto-detects whether it's in seconds (10 digits), milliseconds (13 digits), or microseconds (16–17 digits), then shows the result in your local time, UTC, ISO 8601, RFC 2822, and as a friendly relative format like '3 hours ago'. Every output has a one-click copy button.

Timestamp → date and date → timestamp

The Timestamp → date panel accepts any positive or negative Unix timestamp. Negative timestamps represent dates before 1970 — Unix timestamp −86,400 is 31 December 1969 00:00:00 UTC. Override the auto-detected unit to force seconds, milliseconds, or microseconds when you know exactly what format you have.

The Date → timestamp panel works the other way: pick any date and time, choose your timezone from the full IANA timezone list, and get the exact Unix seconds and milliseconds for that moment. It defaults to the current time so you can see today's epoch immediately.

Discord timestamp tags — generate all seven formats

Discord renders Unix timestamps in chat messages using tags like <t:1700000000:F>, which Discord's client shows in each reader's local timezone automatically. There are seven format codes: t (short time), T (long time), d (short date), D (long date), f (short date and time — the default), F (long date and time with day of the week), and R (relative — 'in 3 hours', '2 years ago').

Most Discord timestamp generators only produce one or two of the seven formats — hammertime.cyou generates all seven but requires a separate site visit and has no epoch auto-detection. This tool generates all seven at once, with a preview of how each will render in your local time, and a copy button for each tag. Works on iPhone, Android, and desktop.

How this compares to EpochConverter.com and unixtimestamp.com

EpochConverter.com is the category leader — it handles second and millisecond timestamps well and is fast. But it doesn't auto-detect the scale (you specify seconds vs ms), has no Discord tag generator, and shows no microsecond support. Unixtimestamp.com is simpler still — seconds only, no Discord output, no relative time.

This tool auto-detects all three scales by digit count, generates all seven Discord format tags, shows relative time, and runs entirely in your browser with no account. For developers who need to debug log files, API responses, and Discord bots in a single tab, that combination isn't available on either of those sites.

Auto-detect seconds, milliseconds, and microseconds

The most common source of confusion with Unix timestamps is scale. A seconds timestamp like 1700000000 has 10 digits and represents a date in November 2023. The same moment as a milliseconds timestamp is 1700000000000 — 13 digits, one thousand times larger. JavaScript's Date.now() returns milliseconds; the Unix shell command date +%s returns seconds. APIs and databases vary widely.

16- and 17-digit timestamps are microseconds — used in high-precision sensor data, distributed tracing, and some NoSQL databases. This converter identifies the scale by digit count and converts correctly every time. You can also override the detection and force a specific unit.

Epoch conversion in Python, JavaScript, and SQL

In Python, convert with datetime.fromtimestamp(ts, tz=timezone.utc) for UTC, or omit tz to get the result in the server's local timezone (which causes bugs on different machines). The current seconds timestamp is int(time.time()); milliseconds is int(time.time() * 1000). In JavaScript, new Date(ts * 1000) turns a seconds timestamp into a Date object; Date.now() gives the current milliseconds epoch.

In MySQL, UNIX_TIMESTAMP() returns the current epoch in seconds and FROM_UNIXTIME(ts) converts back to a datetime. In PostgreSQL, EXTRACT(EPOCH FROM timestamptz) gives the seconds epoch and TO_TIMESTAMP(ts) converts the other way. This tool handles the edge cases that catch developers out: the Year 2038 problem, negative timestamps before 1970, and all three precision scales.

Private, offline-capable, and instant

Every conversion runs locally in your browser — there is no server, nothing is uploaded, and no network requests are made. The page works after it has loaded even when you are offline. Bookmark it for quick access the next time you find a suspicious-looking integer in a log file, API response, database record, or JWT payload and need to know what date and time it represents.

Why January 1, 1970? The origin of the Unix epoch

The choice of January 1, 1970 00:00:00 UTC as the Unix epoch was pragmatic rather than ceremonial. Engineers at Bell Labs needed a fixed reference point while building the first Unix systems around 1969–1971. They wanted a round number close to the present day so that typical timestamps would be small, positive integers that fit comfortably in the 32-bit words available at the time. 1970 was the nearest round year to when the work was being done, and it stuck permanently.

One important subtlety is that POSIX time ignores leap seconds. UTC occasionally inserts a leap second to keep atomic time aligned with Earth's rotation — for example, a leap second was added at the end of 2016. POSIX treats every day as exactly 86,400 seconds regardless, so Unix timestamp 1483228800 corresponds to 2017-01-01 00:00:00 UTC whether or not a leap second occurred at the previous midnight. This means Unix time is not a perfectly linear count of SI seconds, but it is consistent and unambiguous for the date–time conversions that almost every application cares about.

UTC (Coordinated Universal Time) and GMT (Greenwich Mean Time) are often used interchangeably in documentation, but they are technically different. GMT is an astronomical standard based on the rotation of the Earth; UTC is maintained by atomic clocks and kept within 0.9 seconds of GMT by the periodic insertion of leap seconds. For all practical timestamp work the distinction is irrelevant — the two differ by at most a fraction of a second — but UTC is the correct term for the reference used in Unix time.

The Year 2038 problem: when 32-bit timestamps overflow

A 32-bit signed integer can hold values from −2,147,483,648 to 2,147,483,647. When Unix timestamps are stored in that type — as they were in early Linux kernels and many C programs written before 64-bit computing became universal — the counter reaches its ceiling at 03:14:07 UTC on January 19, 2038. One second later the value wraps to the largest negative 32-bit integer, which the system interprets as a date in December 1901. This is the Year 2038 problem, sometimes called Y2K38.

The practical risk is concentrated in long-lived code bases that have never been modernised: embedded systems in industrial controllers and medical devices, firmware in network equipment, old database schemas that store timestamps as INT columns rather than proper datetime types, and legacy C libraries. The fix is straightforward in principle — migrate to 64-bit integers, which push the overflow date to roughly 292 billion years in the future — but discovering and updating every affected system takes time and testing. Linux migrated its time_t to 64-bit on 32-bit ARM platforms in kernel 5.6 (2020), well ahead of the deadline.

Y2K38 differs from the original Y2K problem in an important way. Y2K was a data representation issue — many systems stored only two digits for the year, so 2000 looked like 1900 — and it required a coordinated software update across virtually every organisation simultaneously. Y2K38 is a data-type overflow in specific systems that happen to use 32-bit timestamps, and modern software written in the last 15 years is almost certainly unaffected. The risk is real but scoped, making it less of a global crisis and more of a targeted audit problem for teams maintaining legacy infrastructure.

ISO 8601 and the case for standardised date strings

ISO 8601 is the international standard that defines how to write dates and times as strings. The canonical form is YYYY-MM-DDTHH:MM:SS±HH:MM — year, month, and day separated by hyphens; a literal T character separating date from time; hours, minutes, and seconds separated by colons; and a timezone offset like +05:30 or the suffix Z to indicate UTC. JavaScript's Date.toISOString() always returns this format with milliseconds and a Z suffix: 2023-11-14T22:13:20.000Z.

The single most useful property of ISO 8601 is that it is lexicographically sortable: sorting the strings alphabetically produces correct chronological order. That property makes ISO 8601 safe to use as a key in file systems, object stores, and databases where you want chronological ordering without parsing. The standard also defines compact forms (20231114 for date-only), week notation (2024-W23-3 means the third day of the 23rd week of 2024), and duration notation (P1Y2M3DT4H). RFC 2822, used in email headers, takes a different approach: Mon, 03 Jun 2024 12:34:56 +0000 — human-readable but not sortable as a string and painful to parse.

Region-specific formats such as MM/DD/YYYY (common in the United States) and DD/MM/YYYY (common in Europe) are fundamentally ambiguous: the string 04/05/2024 means April 5 in one convention and May 4 in the other. These formats are fine for display to end users in a known locale, but they should never be used in data storage, log files, API payloads, or any context where the string will be read by code or by people in a different region. ISO 8601 eliminates the ambiguity entirely.

Time zones in databases: always store UTC, convert on display

The universal best practice for timestamp storage is to always persist in UTC and convert to local time only when rendering for a user. The reason becomes clear at the DST boundary known as the 'fall back': when clocks in the US Eastern timezone roll back from 2:00 AM to 1:00 AM, the local time 1:30 AM occurs twice in the same night. A system storing local time has no way to distinguish the first 1:30 AM from the second without additional context. UTC has no daylight saving shifts, so the two instants have completely different UTC values and are always unambiguous.

PostgreSQL makes the distinction explicit with two separate column types. TIMESTAMP WITH TIME ZONE (also written TIMESTAMPTZ) always converts the input to UTC on storage and re-applies the session timezone on retrieval — regardless of what offset you supplied when inserting the row. TIMESTAMP WITHOUT TIME ZONE stores exactly the string you provide, with no timezone awareness at all. If you insert 2024-03-10 02:30:00 into a TIMESTAMP WITHOUT TIME ZONE column, that literal value is what comes back, even though that particular instant does not exist on US clocks because it falls inside the DST spring-forward gap. MySQL has the same split: TIMESTAMP normalises to UTC; DATETIME stores the literal value with no conversion.

When encoding timezone information in ISO 8601 strings, prefer IANA timezone names (America/New_York, Europe/Berlin) over fixed UTC offsets (-05:00). A fixed offset is correct only at a specific instant; it cannot capture the fact that America/New_York is -05:00 in winter and -04:00 in summer. Libraries like Luxon, date-fns-tz, and Python's zoneinfo module use the IANA database to resolve the correct offset for any moment in time, automatically accounting for DST transitions, historical offset changes, and future rule updates.