Epoch Converter

How the epoch converter works

Computers do not track time with calendars and clocks. They track it with a single counter: the number of seconds elapsed since one fixed starting point. That counter is the Unix timestamp, and this tool moves between it and the dates people actually read, in both directions.

What the Unix epoch is

The Unix epoch is the moment the counter starts: midnight UTC on 1 January 1970. A timestamp of 0 is exactly that instant. Every second after it adds 1, so a timestamp of 86400 is one full day later (24 hours times 60 minutes times 60 seconds), which is 2 January 1970 00:00:00 UTC.

Because a timestamp is one plain number tied to UTC, it does not depend on time zones, date formats, or daylight saving rules. That makes it ideal for storing and comparing moments in time: sorting by timestamp always puts events in chronological order.

Seconds versus milliseconds, and how detection works

Two flavors of the timestamp are common:

• Seconds is the classic Unix format. A present-day value is 10 digits, for example 1700000000.
• Milliseconds is what JavaScript’s Date.now() and many APIs return. It is the same count multiplied by 1000, so the same moment is 13 digits, for example 1700000000000.

This converter auto-detects which one you pasted. Any value with a magnitude of 1e12 (one trillion) or larger is read as milliseconds; anything smaller is read as seconds. That threshold works cleanly because seconds-based timestamps do not reach a trillion until the year 33658, while millisecond timestamps crossed a trillion back in 2001.

UTC versus local time

A timestamp names an absolute instant, but two people in different cities will write that instant on their clocks differently. So the result shows two lines:

• UTC, Coordinated Universal Time, the global reference. It never shifts for daylight saving and is the value most servers and logs use.
• Local time, which is UTC adjusted by your device’s time-zone offset.

The underlying number is the same; only the displayed clock changes. When you go the other way, the datetime-local input reads your entry as local time and converts it to the universal timestamp for you.

A worked example

Take the timestamp 1700000000:

1. It is 10 digits, so it is read as seconds.
2. Counting that many seconds from 1 January 1970 UTC lands on 14 November 2023.
3. The leftover seconds within that day work out to 22:13:20.

So 1700000000 is Tuesday, 14 Nov 2023 22:13:20 UTC. Feed in 1700000000000 instead (13 digits) and it is read as milliseconds, resolving to the very same moment.

The year 2038 problem

Older software stores the timestamp in a signed 32-bit integer, which tops out at 2,147,483,647 seconds. That ceiling arrives at 03:14:07 UTC on 19 January 2038. One second later the value overflows into a negative number and the date jumps back to 1901, a bug nicknamed the “Y2K38” problem. Modern systems store time in 64-bit integers, which move the limit hundreds of billions of years out, so the risk today is concentrated in legacy 32-bit code and embedded devices.

Common uses

• Logs and monitoring: most server logs stamp each line with an epoch value so entries sort and compare without time-zone confusion.
• APIs: REST and JSON APIs frequently return created_at or expires_at as timestamps; converting them makes a response readable.
• Databases: storing a timestamp column keeps dates compact and unambiguous, and lets queries range over time cheaply.
• Debugging: when a JWT, cookie, or cache entry lists an exp field, dropping it in here tells you instantly whether it is expired.

A timestamp is a representation of a moment, not a secret. Anyone can convert it back to a date in an instant, so treat it as data, not security.