Unix Timestamps: The Year 2038 Problem and Why Your Date Is in 33,000 AD

If you have ever pasted a Unix timestamp into a tool and seen "Jan 1, 33658 AD" come back, you have encountered the unit-mismatch problem. The fix is always the same - you pasted milliseconds expecting seconds, or vice versa - but it catches every developer at least once. This post is the full explanation of what Unix timestamps are, the units they come in, the bizarre year 2038 problem that is going to be real for some systems, and why my Toolium tool auto-detects the unit.

What a Unix timestamp is

A Unix timestamp is the number of seconds elapsed since the "Unix epoch" - January 1, 1970, 00:00:00 UTC. Today, in mid-2026, the current Unix timestamp is around 1,782,000,000. It is a 10-digit number that grows by 1 every second.

Why this odd starting point? Because Unix (the operating system) was designed in the late 1960s at Bell Labs, and the designers picked a date close enough to be useful but not so recent that early values would be tiny. January 1, 1970 was already a few years in the past at the time. The choice stuck.

The advantages of representing time this way:

• Timezone-independent. A Unix timestamp represents an absolute moment in time. Two computers in different timezones agree on the timestamp even though they would render it as different wall-clock times.
• Sortable. Larger timestamps mean later times. Comparing two timestamps is just integer comparison.
• Math is easy. Adding 86,400 advances by exactly one day. Subtracting two timestamps gives the elapsed seconds.
• Universal. Every programming language and database supports them. There is no ambiguity about format.

The seconds-vs-milliseconds confusion

The original Unix timestamp used seconds. JavaScript decided, when it was designed in the 1990s, to use milliseconds instead - the number of milliseconds since the epoch. This gives sub-second resolution without needing fractional values.

The result: modern systems use both conventions. Most server-side languages (Python, Ruby, PHP, Go, Rust) default to seconds. JavaScript, Java, and most JSON-based APIs use milliseconds. Some high-precision systems (Twitter's Snowflake IDs, some logging frameworks) use microseconds (16 digits) or nanoseconds (19 digits).

The unit-mismatch bug: a system that stores milliseconds (1,782,000,000,000) gets read as seconds, producing a date around the year 58,438. Or seconds (1,782,000,000) gets read as milliseconds, producing a date a few weeks after the epoch in February 1970.

The Toolium Timestamp Converter auto-detects: a 10-digit number is seconds, a 13-digit number is milliseconds, a 16-digit number is microseconds. You can also explicitly pick a unit if you have edge cases (very early dates, very far future, etc.).

The 2038 problem

Many older systems store Unix timestamps as 32-bit signed integers. The maximum value of a 32-bit signed integer is 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC. After that moment, the timestamp overflows. The value becomes negative, and most systems interpret negative timestamps as dates in 1901.

This is the "Year 2038 problem," and it is real. Many embedded systems, older databases, and some legacy network protocols still use 32-bit timestamps. They will all need to be updated or replaced before 2038.

Modern systems use 64-bit signed integers, which give roughly 292 billion years of headroom in either direction. The year 2038 problem does not affect 64-bit systems. But if you are working on embedded software, IoT devices, or anything that touches old legacy protocols, the migration is worth thinking about now.

Negative timestamps

Timestamps before the epoch (before January 1, 1970) are represented as negative numbers. -1 is December 31, 1969 at 23:59:59 UTC. -86,400 is December 31, 1969 at 00:00:00 UTC. -10,000,000,000 is around 1653 AD.

Negative timestamps work in 64-bit systems but can cause bugs in older code that assumes timestamps are positive. The Toolium converter handles negative timestamps correctly, including for dates back to the 1800s.

Leap seconds (and why Unix ignores them)

Earth's rotation is slowly slowing down due to tidal forces from the Moon. To keep atomic-clock-based time aligned with astronomical time, the international time-keeping authority occasionally inserts "leap seconds" - extra seconds inserted at the end of a day. As of 2026, 27 leap seconds have been inserted since 1972.

Unix time, by convention, ignores leap seconds. Each Unix day is exactly 86,400 seconds, even though astronomical days are very slightly longer or shorter. This means Unix timestamps drift from astronomical time by a few seconds per decade, but it makes time arithmetic vastly simpler.

For most software this is fine. For astronomy software, GPS navigation, or anything else that needs astronomical accuracy, you need TAI (atomic time) or UT1 (astronomical time), neither of which is what Unix timestamps represent.

Timezones (briefly)

A Unix timestamp does not have a timezone - it represents an absolute moment. When you convert a timestamp to a human-readable date, you pick the timezone for the display. The Toolium converter shows the timestamp in both UTC and your local timezone (determined by your browser).

For converting to a specific other timezone, do the UTC conversion first, then apply the offset manually or in a date library.

The Toolium converter

The Timestamp Converter goes both directions: paste a timestamp to get the human date, or paste a date to get the timestamp. It auto-detects the unit (seconds, ms, or μs) but lets you override. Output includes both UTC and your local timezone. The current time is shown live, updating every second, which is useful when you need to grab "right now" as a timestamp.