Somewhere in every log file, every API response and every database row there is a
number like 1756684800, and it means a moment in time. This is Unix
time: the count of seconds since midnight UTC on 1 January 1970. It looks
unfriendly, but it exists because it solves the two hardest problems in
timekeeping — timezones and formats — by simply refusing to have either.
One instant, one number
A wall-clock date like "2 September 2026, 09:00" is ambiguous until you say where
the clock was hanging. Nine in the morning in Kolkata and nine in the morning in
New York are different instants, nine and a half hours apart. A Unix timestamp has
no such ambiguity: it counts from a fixed instant — the epoch — so
1756684800 is the same moment for everyone on the planet.
That is why systems store and exchange timestamps rather than dates. The timezone is applied at the last possible moment, when a human needs to read the value — and only then does "which zone?" have to be answered.
Seconds, milliseconds, and the 1970 bug
The classic timestamp confusion is the unit. Unix tradition counts seconds;
JavaScript's Date.now() returns milliseconds; some databases and
tracing systems use microseconds or nanoseconds. The same instant is
1756684800, 1756684800000,
1756684800000000 or 1756684800000000000 depending on
who produced it.
Fortunately the units are three orders of magnitude apart, so a glance at the digit count settles it: a present-day timestamp has ten digits in seconds and thirteen in milliseconds. Mix them up and the failure is unmistakable — read milliseconds as seconds and dates land tens of thousands of years in the future; make the opposite mistake and everything happens in January 1970. If you have ever seen a user list where everyone signed up on 1 January 1970, you have seen this bug. Our converter detects the unit from the magnitude automatically.
2038: when 32 bits run out
Store seconds in a signed 32-bit integer and the largest value you can hold is 2,147,483,647 — which is 03:14:07 UTC on 19 January 2038. One second later the number wraps around to −2,147,483,648, and the date reads 13 December 1901.
Modern operating systems moved time to 64 bits years ago, which pushes the limit out by about 292 billion years. But the 32-bit assumption is baked into old embedded devices, file formats, network protocols and database columns — and unlike Y2K, nobody can patch a sealed unit bolted into an industrial controller from 2009. It is a slow-motion deadline, and it is real.
What Unix time deliberately ignores
Unix time pretends every day is exactly 86,400 seconds. It is not — the Earth's rotation wobbles, and leap seconds are occasionally inserted to keep atomic time aligned with it. When one happens, Unix time repeats a second rather than counting it.
That is a deliberate trade. Because every day has the same length, converting a timestamp to a date is pure arithmetic — no leap-second table required, no updates when the next one is announced. The cost is that subtracting two timestamps across a leap second is off by one physical second, which matters to astronomers and to almost nobody else.
The timezone trap in the other direction
Reading a timestamp is safe; producing one is where bugs live. A date
string without an offset, like 2026-09-02, does not identify an
instant — and different parsers guess differently. JavaScript parses that exact
string as UTC midnight, so for anyone west of Greenwich it renders as
1 September. The rule that avoids the whole class of bugs: keep timestamps for
storage and arithmetic, attach an explicit zone the moment anything becomes a
string, and treat a bare date as a calendar concept rather than an instant.
FAQ
How do I tell whether a timestamp is in seconds or milliseconds?
By its size. A present-day timestamp is about 1.8 billion in seconds but about 1.8 trillion in milliseconds — ten digits versus thirteen. Anything under about 100 billion is almost certainly seconds; thirteen digits means milliseconds. The classic giveaway of a unit mix-up is a date near January 1970, which is what you get when milliseconds are read as seconds after dividing, or a date tens of thousands of years away when seconds are read as milliseconds.
What is the year 2038 problem?
Many older systems store Unix time as a signed 32-bit integer, which runs out at 2,147,483,647 — 03:14:07 UTC on 19 January 2038. One second later the value wraps to a large negative number, which reads as December 1901. Modern 64-bit systems are unaffected, but embedded devices, old file formats and legacy databases that hard-coded 32-bit time fields will misbehave unless they are updated.
Do Unix timestamps change with timezones?
No — that is the whole point. A Unix timestamp counts seconds since 00:00:00 UTC on 1 January 1970 and identifies one instant, everywhere. Only its rendering as a wall-clock date depends on a timezone. Going the other way does depend on the zone: "2 September 2026, 09:00" is a different instant in Kolkata than in New York, so converting a date to a timestamp must say which zone the date was in.
Does Unix time count leap seconds?
No. When a leap second is inserted, Unix time repeats a second instead of counting it, so every day is exactly 86,400 Unix seconds long. That makes date arithmetic simple and means Unix time is not, strictly, the number of physical seconds elapsed since 1970 — it is a few dozen seconds short. For almost everything outside astronomy and precision timekeeping, this is a feature rather than a bug.
Related guides
- UUID v4 versus v7 — v7 embeds one of these timestamps in its first 48 bits, and that is exactly why databases like it.
- How age calculation actually works — what happens when instants meet calendars, and why the arithmetic gets strange.
- Cron expressions, and the OR trap — scheduling against these same clocks, with a timezone trap of its own.
Try it now: Free Unix Timestamp Converter