Epoch & Unix Timestamp Converter

How to use it

1. Paste a timestamp and every format appears — or pick a date and get the timestamp instead. Both directions are on screen at once.
2. Check what unit it assumed. If the number was read as milliseconds when you meant seconds, a note says so and the dropdown overrides it.
3. Copy the row you need. The UTC and ISO rows are the safe ones to quote in a bug report.

The live clock at the top is the current timestamp, ticking. Copy it, or press “Use it” to load it below.

Seconds or milliseconds?

This is the reason the tool detects the unit instead of asking you to pick one. It is comfortably the most common epoch bug.

JavaScript’s Date.now() returns milliseconds. Python’s time.time(), PHP’s time(), Go’s Unix() and the overwhelming majority of APIs return seconds. Put one where the other belongs and nothing errors — you just get a date that is wrong by a factor of a thousand.

The quick check: a present-day timestamp in seconds is 10 digits. Thirteen digits means milliseconds — divide by 1000. Sixteen means microseconds, which you will mostly meet in database columns and tracing systems.

The failure is silent in both directions. Treat seconds as milliseconds and you land in January 1970. Treat milliseconds as seconds and you land around the year 58,000. Neither throws an error anywhere.

What Unix time actually is

A count of seconds since 1 January 1970, 00:00:00 UTC — the Unix epoch.

The date was chosen for convenience, not significance: the engineers building early Unix needed a starting point near the present, and 1970 was a round number just behind them.

The useful property is that it carries no timezone. A Unix timestamp refers to one instant, the same instant for everyone. Two servers on opposite sides of the planet agree on it exactly, with no conversion and no ambiguity about whether you meant EST or EDT. That is why it is what systems store internally, and why a written-out date is what they show you at the last possible moment.

Reference points

Useful rules of thumb: a 10-digit timestamp starting 17 is somewhere in the mid-2020s, one starting 16 is the early 2020s, and one starting 9 is the 1990s. That is usually enough to sanity-check a value before converting it.

The 2038 problem

A signed 32-bit integer holds values up to 2,147,483,647. As a Unix timestamp that is 03:14:07 UTC on 19 January 2038.

One second later, a system storing time that way overflows to the most negative value it can hold, and the date reads as December 1901. It is the same class of bug as Y2K, with the same fix: use more bits.

Most modern systems already do. 64-bit time_t is standard on current Linux, macOS and Windows, and it pushes the ceiling roughly 292 billion years out. What remains exposed is the awkward long tail — embedded controllers, industrial equipment, older file formats, some database columns declared as 32-bit integers, and anything storing dates as `int` because it seemed like enough at the time.

If you work with systems that will still be running in 2038, the value worth testing against is 2147483648: one second past the ceiling. This tool flags any timestamp beyond it.

Dates before 1970

They are negative, and they work here.

A surprising number of tools reject a negative timestamp or silently clamp it to zero, which turns every historical date into 1 January 1970. If you are storing birth dates, publication dates or anything else that can predate the epoch, that clamping is a data-corruption bug waiting to happen.

-2208988800 is 1 January 1900. It converts here without complaint.

ISO 8601

The international standard for writing a date and time as text: 2026-08-16T15:30:00Z.

Its best property is that it sorts. Because the components run largest to smallest, sorting ISO strings alphabetically also sorts them chronologically — which means a plain text sort on a log file is a chronological sort, with no parsing at all.

An ISO string with an offset and a Unix timestamp carry the same information. An ISO string with no offset — 2026-08-16T15:30:00 — does not, because nothing says which zone it is in. That form causes real bugs and is worth avoiding in anything stored or transmitted.

Worked example

A log line contains 1786894200 and you need to know when it happened, in London.

1. Paste it in. Ten digits, so it is read as seconds.
2. Set the timezone to Europe/London.

Note the two ISO rows differ by an hour and both are correct — London is on British Summer Time in August. Same instant, two ways of writing it. The UTC row is the one to paste into a ticket.

Converting in code

The JavaScript row is where the milliseconds trap lives: Date.now() gives milliseconds, and the * 1000 going the other way exists for the same reason. Miss either and you are out by a factor of a thousand.

Why your timestamp shows the wrong date

Five causes, in rough order of frequency.

1. Wrong unit. Off by a factor of 1000 in either direction. Covered above, and it accounts for most of them.
2. Timezone applied twice. A timestamp is already UTC. Convert it to local time, then apply an offset again, and you are out by the offset. This is endemic in code that mixes a date library with manual arithmetic.
3. A string that was never parsed. "1786894200" as a string, concatenated rather than added, produces nonsense silently in loosely typed languages.
4. Seconds stored in a 32-bit column. Fine until 2038, then negative. Also fine until someone stores a date in 1901 and it wraps the other way.
5. Local midnight assumed to be UTC midnight. They are only the same in UTC+0. Everywhere else, “today” starts at a different instant, which is why daily-aggregate reports so often disagree by a few rows.

Storing time properly

Since this page exists because time handling goes wrong, the short version of doing it right:

• Store UTC. Always. Convert to local only when displaying, at the last possible moment.
• Store the timezone separately if you need to know where an event happened. An offset is not a timezone — +01:00 does not tell you whether it was London in summer or Berlin in winter, and the distinction matters the moment daylight saving shifts.
• Use a 64-bit integer or a real timestamp type. Not a 32-bit int, and not a string.
• For future events, store the local time and the zone, not the computed UTC instant. Governments change daylight saving rules with months of notice, and a meeting booked for “09:00 in Chicago next March” should move with the rule change rather than drift an hour.

That last one is the counterintuitive rule and the one most systems get wrong. Past events are instants and belong in UTC. Future events are intentions, and an intention to meet at 9am survives a change to the timezone database in a way that a precomputed timestamp does not.

Leap seconds

Unix time pretends every day is exactly 86,400 seconds long. It isn’t — the Earth’s rotation is irregular, and leap seconds are occasionally inserted to keep clocks aligned with it.

When one is inserted, Unix time repeats a value rather than incrementing. So a Unix timestamp is not a true count of elapsed seconds since 1970; it is about 30 seconds behind atomic time and the gap grows.

For essentially all purposes this does not matter, and the simplification is deliberate: it means any timestamp can be converted to a date with pure arithmetic, no table of historical leap seconds required. If you are doing satellite work or precision timing, you want TAI rather than Unix time.

Related tools

To post a time in a chat where every reader should see their own local version, the Discord timestamp generator wraps the same Unix value in Discord’s format codes. For comparing a time across several places at once, use the time zone converter, and for the gap between two dates the date duration calculator. Scheduled jobs fire on the same instants — the cron expression generator shows the next ten in a timezone you name. JWT tokens carry exp and iat as raw Unix seconds, and the JWT decoder turns those into readable dates for you.