The 10-Digit vs 13-Digit Trap: A Practical Guide to Unix Epoch Timestamps

A few years ago, our customer support team flagged an urgent ticket with an impossible screenshot. A customer in London had just completed an e-commerce checkout, but their confirmation email declared that their order had been placed on January 18, 1970, at roughly 4:30 AM.

The customer was convinced our database had been hacked by time travelers. The actual culprit was far more mundane: our Python backend was emitting a standard Unix timestamp in seconds (a 10-digit number like 1720742400), while our React frontend was passing that raw number straight into JavaScript’s new Date(timestamp).

JavaScript dates expect milliseconds (a 13-digit number). Because the frontend received ten digits instead of thirteen, it interpreted the timestamp as approximately 1.7 million milliseconds after the Unix epoch—which lands you squarely in the third week of January 1970.

Spoiler: nobody hacked us. We just forgot three zeroes.

If you write software for long enough, you will inevitably run into this exact trap. Dates and times in computer systems are notoriously deceptive. They look simple until you cross language boundaries, handle leap seconds, deal with daylight saving changes, or parse timestamps across distributed microservices.

Here is a practical guide to how Unix timestamps work, why the seconds versus milliseconds distinction trips up almost every developer, and how to debug timestamp issues without leaking production logs to third-party conversion sites.

What Is the Unix Epoch, Anyway?

Computers do not understand calendars, moon phases, or the Gregorian reform of 1582. They understand numbers that increment.

To give computing systems a universal clock, the engineers at Bell Labs working on early Unix in the early 1970s picked an arbitrary fixed reference point: 00:00:00 Coordinated Universal Time (UTC) on Thursday, January 1, 1970.

This starting line is known as the Unix Epoch.

A Unix timestamp is simply the number of seconds that have ticked by since that precise moment in 1970, excluding leap seconds. If the timestamp is 0, it is midnight on January 1, 1970. If the timestamp is 60, it is 00:01:00 UTC on the same morning.

That simplicity is why Unix timestamps became the standard for databases, log files, JWT auth tokens, and network protocols. You don’t have to argue about whether "04/05/2026" means April 5th (US format) or May 4th (UK and Indian format). A single integer represents an unequivocal moment in human history.

The 10-Digit vs 13-Digit Trap

The single most common bug with Unix timestamps boils down to unit resolution. Different programming environments measure time at different granularities:

1. Seconds (10 digits): Standard in POSIX C, Python’s time.time(), PHP’s time(), MySQL’s UNIX_TIMESTAMP(), and Redis. Currently, a 10-digit timestamp looks like 1773000000.
2. Milliseconds (13 digits): Standard in JavaScript (Date.now()), Java (System.currentTimeMillis()), and modern browser APIs. Currently, a 13-digit timestamp looks like 1773000000000.
3. Microseconds (16 digits): Common in high-resolution Python loggers (time.time_ns() // 1000) and PostgreSQL microsecond timestamps.
4. Nanoseconds (19 digits): Standard in Go (time.Now().UnixNano()), Rust, and distributed tracing systems like OpenTelemetry.

Here is the mental rule of thumb I tell junior engineers: count the digits before doing math.

If you see a ten-digit number starting with 17 or 18, you are looking at seconds. If you see a thirteen-digit number starting with 17 or 18, you are looking at milliseconds.

When you pass a 10-digit timestamp into JavaScript’s new Date(), you must multiply it by 1000. Conversely, if you are sending a JavaScript timestamp to a Python backend expecting POSIX seconds, you must divide it by 1000 using Math.floor().

When debugging strange timestamp behavior in log outputs, you can paste the raw number into our Unix Timestamp & Epoch Converter. It automatically detects whether your input has 10, 13, 16, or 19 digits, shows the corresponding UTC and local times, and tells you right away if your value is off by a factor of one thousand.

The Year 2038 Problem (Y2K38)

You might remember the media circus around the Y2K bug in the late 1990s. While Y2K was mostly resolved by updating two-digit year representations, a real mathematical deadline is silently ticking inside older computer systems: The Year 2038 Problem.

In 32-bit systems, timestamps were stored as a signed 32-bit integer (int32). The maximum positive integer that a signed 32-bit container can hold is:

2,147,483,647

If you add that number of seconds to the Unix epoch (January 1, 1970), you arrive at Tuesday, January 19, 2038, at 03:14:07 UTC.

What happens one second later?

The integer overflows into negative territory: -2,147,483,648.

To an unpatched 32-bit computer, the clock will instantly jump backward 136 years to December 13, 1901. Embedded hardware, older telecom switches, automotive control modules, and legacy database systems running on 32-bit kernels will crash or miscalculate interest, loan amortization, and security certificate expirations.

Modern 64-bit operating systems and languages have largely fixed this by switching to 64-bit signed integers (int64). A 64-bit timestamp won’t overflow for approximately 292 billion years, which outlasts the expected lifespan of our solar system.

That said, if you work with older embedded devices or legacy MySQL columns defined as INT(11) instead of BIGINT, keep 2038 on your architectural radar.

The Great Timezone Illusion

Here is an architectural fact that trips up even experienced engineers: a Unix timestamp has no timezone.

I repeat: there is no such thing as an “Indian Standard Time timestamp” or a “New York timestamp.”

A Unix timestamp is an absolute scalar value. It counts ticks since an absolute moment in Greenwich, London. When the clock strikes 1720742400, that integer is identical whether you are sitting in Tokyo, Bengaluru, Berlin, or San Francisco.

Timezones only exist when you translate that raw integer into human-readable strings (like "2026-07-12 14:00:00 IST"). The timezone is merely the cultural and geographical lens through which a human looks at the universal counter.

When storing timestamps in databases or transmitting them between backend microservices, always store and transmit raw UTC timestamps or ISO 8601 strings with explicit offsets. Never store pre-formatted local time strings in your database without an offset, or you will regret it the minute you have to coordinate across regions using utilities like the Timezone Overlap Tool.

Why Client-Side Timestamp Inspection Matters

When an API fails or a user reports an authentication rejection, your first instinct might be to grab the timestamp from the server log and paste it into an online converter.

Here is the risk: production logs often bundle timestamps with IP addresses, user identifiers, and transaction metadata. Pasting that snippet into a server-backed conversion site logs your infrastructure details on their servers.

Our Unix Timestamp & Epoch Converter runs entirely within your browser tab. It handles bidirectional conversion (Epoch to Human Date and Human Date to Epoch), shows your local offset against UTC, and computes time-until or time-since intervals without transmitting a single packet over the network.

Double-check your unit resolution before shipping your API contracts, keep your stored timestamps in UTC, and if you ever hit an odd timestamp format that our converter trips over, let me know through the Suggest a Tool page.