Skip to tool
ecech.
🕑 Date, Time & Timezone

Free Epoch and Unix Timestamp Converter with Auto Precision Detection

Paste any epoch number and it works out whether you gave it seconds, milliseconds or microseconds — then shows the date in UTC, your local zone and every common format.

Right now

Result

Every common representation

Advertisement

How the calculation works

How many digits? That is how you know the unit. 1754150400 10 digits → seconds the classic Unix epoch, used by most APIs and databases 1754150400000 13 digits → milliseconds JavaScript Date.now(), Java, Kafka, most log pipelines 1754150400000000 16 digits → microseconds Postgres internals, tracing spans, high-resolution metrics Feed milliseconds to a seconds parser and you land in the year 57,000. Feed seconds to a millisecond parser and you land in 1970.

How to Use This Tool

A timestamp is just a count of how long it has been since midnight UTC on 1 January 1970. That single number is unambiguous, timezone-free and easy to sort, which is why it is everywhere in logs, databases and APIs. It is also completely unreadable, and the number you have been handed might be counting seconds, milliseconds or microseconds with nothing to tell you which.

Converting a timestamp

Paste the number and the tool detects the precision from its magnitude, then says so explicitly rather than guessing silently. This is the part that goes wrong most often: pass a millisecond value to something expecting seconds and you get a date roughly fifty thousand years in the future; pass seconds where milliseconds are expected and everything collapses to January 1970. Both failures show up in production logs constantly, and both are instantly obvious once the date is rendered.

The result is shown in UTC and in your browser's local timezone side by side. Read the offset carefully. A timestamp itself has no timezone — the same number is the same instant everywhere on earth. The timezone only appears when you format it for a human, which is precisely why storing local time in a database and timestamps in logs causes so much confusion during an incident.

One timestamp: 1754150400 — the same instant, four clocks the instant Los Angeles Aug 2, 09:00 −07:00 London Aug 2, 17:00 +01:00 Taipei Aug 3, 00:00 +08:00 Auckland Aug 3, 04:00 +12:00 Note the date differs by a day in two of them. The number never did.
Store and transmit the epoch value; convert to local time only at the moment you display it. Every timezone bug you have ever debugged came from doing those two steps in the wrong order.

Going the other way

Switch to Date → timestamp to convert a calendar date into an epoch value. The interpret as selector matters more than it looks: entering "2026-08-02 09:00" and treating it as local time produces a different number from treating it as UTC, by exactly your offset. When you are constructing a query filter or a test fixture, choosing the wrong one shifts your whole result set by several hours.

Formats you will actually be asked for

The list at the bottom gives ISO 8601 with and without offset, the RFC 2822 form that HTTP headers and email use, a SQL-friendly form, and a plain human sentence. Copy whichever the receiving system expects. ISO 8601 with an explicit offset is the safest default for anything crossing a system boundary, because it is unambiguous and sorts correctly as a string.

Advertisement

Frequently Asked Questions

How do I tell if a timestamp is in seconds or milliseconds?
Count the digits. A current timestamp in seconds has 10 digits; in milliseconds it has 13; in microseconds it has 16. This tool detects it automatically and tells you which it assumed. If a date comes out in 1970 you fed seconds to a millisecond parser; if it comes out tens of thousands of years in the future you did the reverse.
Why does my timestamp show a different date than I expected?
Almost always a timezone issue. The epoch value is the same instant everywhere, but the calendar date attached to it depends on the offset used to display it. Near midnight, UTC and your local zone can show different days. The tool shows both so the discrepancy is visible rather than mysterious.
Does a Unix timestamp have a timezone?
No, and this is the single most useful thing to understand about it. It counts seconds since a fixed instant, so it is timezone-free by construction. A timezone only enters when you format it for display. Store timestamps, convert at the edge, and most timezone bugs disappear.
What is the year 2038 problem?
Systems storing timestamps in a signed 32-bit integer overflow on 19 January 2038, wrapping to 1901. Modern 64-bit systems are unaffected and will be fine for about 292 billion years, but embedded devices, old file formats and some legacy databases still use 32-bit time fields.
Why do some timestamps look negative?
They represent dates before 1 January 1970. Negative epoch values are legal and useful for historical dates, but support varies — some languages and databases handle them correctly and others fail or produce nonsense. If you are storing birth dates or historical records, test this explicitly rather than assuming.
What about leap seconds?
Unix time deliberately ignores them. It assumes every day is exactly 86,400 seconds, so during a leap second the counter either repeats a value or is smeared across a period, depending on the system. For almost all applications this is irrelevant; for high-precision timing it is not, and you need TAI rather than Unix time.
Which format should I use for an API?
ISO 8601 with an explicit offset, such as 2026-08-02T17:00:00+01:00, or the epoch integer with the unit documented. Both are unambiguous. Avoid formats like 02/08/2026, which means two different dates depending on which side of the Atlantic reads it, and avoid local time without an offset entirely.

What people usually need next

Picked by hand, not by algorithm.

Related tools in Date, Time & Timezone

Browse all Date, Time & Timezone tools