Unix Timestamps and Time Zones: Seconds vs Milliseconds, UTC, and the Year 2038 Problem

1700000000 is a perfectly ordinary Unix timestamp — Tuesday, 14 November 2023, 22:13:20 UTC. Almost every bug involving one comes down to the same handful of mix-ups: seconds read as milliseconds (or the reverse), a timestamp compared against the wrong time zone, or — much further out — the numeric limit a 32-bit system eventually runs into. None of these need to be mysterious once the format itself is clear.

What a Unix timestamp actually is

A Unix timestamp is a single number: the count of seconds that have elapsed since 1 January 1970, 00:00:00 UTC — the "Unix epoch." It has no time zone of its own; it's an absolute point in time expressed as a count, which is exactly why it's the format of choice for storing and comparing times across systems in different regions — there's no ambiguity to resolve until you convert it into a human-readable date somewhere. Negative values are valid too, and simply represent dates before 1970 — for example, -86400 is exactly one day before the epoch.

Try a few values in the Unix Timestamp Converter: 0 is 1 January 1970, 00:00:00 UTC exactly, and the converter always shows the result in UTC — see below for why that matters when you're also thinking in your own local time.

Seconds vs. milliseconds — the single most common mix-up

Unix time is defined in seconds, but a lot of software — JavaScript's Date.now() among them — works in milliseconds since the same epoch instead, and the two are easy to conflate. The Unix Timestamp Converter tells them apart by length: a value of 13 or more digits is treated as milliseconds, and anything shorter as seconds.

That threshold isn't arbitrary. A present-day timestamp in seconds is 10 digits (roughly 1.7–1.8 billion right now); the same instant in milliseconds is 13 digits, a thousand times larger. Seconds-based timestamps won't even reach 11 digits until 20 November 2286 — verified directly by converting 10,000,000,000 seconds to a date — and won't reach 13 digits for tens of thousands of years after that. So today, and for a very long time to come, a 13-digit value can only sensibly mean milliseconds, which is exactly the rule the converter relies on.

There's a second, rarer trap one step further out: a 16-digit number is most likely microseconds (a unit some databases and logging systems use), not milliseconds — but the converter's rule only distinguishes seconds from milliseconds at 13 digits, so a microsecond value gets misread as milliseconds and lands on a date thousands of years in the future. If a timestamp is producing a wildly wrong future date, check whether the source system actually uses microseconds, and divide by 1,000 before converting.

UTC vs. local time

The timestamp itself is time-zone-agnostic — it's the human-readable date that has a time zone attached, and that's where confusion usually creeps in. The Unix Timestamp Converter always displays the timestamp-to-date direction in UTC, but converting a date you type back into a timestamp uses your browser's own local time zone — so the same wall-clock time ("2 PM") produces a different timestamp depending on where you are, while a given timestamp always means the exact same instant everywhere. If you need to convert a specific date and time in a specific city or region — not just your own device's local zone — the Time Zone Converter is the more direct tool: it uses the browser's built-in IANA time zone database (the same standard database operating systems and most software rely on) rather than a fixed offset, so it correctly accounts for each region's own daylight saving rules for the specific date you enter, not just a flat "+5:30" or "+1" style shift that would be wrong on a different date.

The year 2038 problem

Some older and embedded systems store a Unix timestamp as a signed 32-bit integer, which can only represent whole numbers up to 2,147,483,647. That value corresponds to 19 January 2038, 03:14:07 UTC — one second later, the number would need a 33rd bit it doesn't have. On an affected system this typically wraps around to a large negative number, which gets interpreted as a date in December 1901 instead of 2038 — the same overflow, mirrored to the other side of zero. Modern systems generally use 64-bit timestamps, which push this limit out to a date so far in the future it isn't a practical concern, but the 32-bit version of the problem is real for older software, some embedded and IoT devices, and certain file formats and databases that were built assuming 32 bits would always be enough.

Putting it together: common bugs and how to spot them

• A date thousands of years in the future or 1970 itself: almost always a seconds/milliseconds mix-up in one direction or the other — check the digit count.
• A date off by several hours from what you expected: usually a UTC vs. local time zone mismatch, not a wrong timestamp — confirm which zone the number is being interpreted in.
• A date that's subtly wrong only in summer (or only in winter): a sign daylight saving time wasn't accounted for — a fixed offset was used instead of an actual time zone conversion.

Since expiry-style claims inside a JWT (exp, iat, nbf) are ordinary Unix timestamps in seconds, the same rules above apply directly there too — see the JWT guide for how those specific claims are read.