What Is a Unix Timestamp and Why Does Computer Time Start in 1970?

Unix timestamp is the simplest possible way to represent a moment in time: count the seconds since 1970-01-01 00:00:00 UTC. That gives code a single number to store, sort, compare, and ship around without dragging calendars and time zones into the mess. If you want to test one by hand, give our free Unix timestamp converter a spin.

What a Unix timestamp actually is

A Unix timestamp is just an integer measured from a fixed starting point called the Unix epoch. In plain terms, 0 means midnight at the start of 1970 in UTC, 1 means one second later, and so on. Negative values can represent times before the epoch, which is useful if you are dealing with historical dates or old records.

The main appeal is that a timestamp behaves like data, not like a human-format date string. You do not need to parse 2026-07-14 09:30:00 before comparing it to another value, and you do not need to care whether the input came from Tokyo, Berlin, or a server running on UTC.

Why computer time starts in 1970

The year 1970 was not chosen because someone had a dramatic love of bell-bottoms. Unix needed a practical zero point, and 1970 was a clean reference that worked well for the era of early Unix systems. It was recent enough to be useful, far enough in the past to give room for both positive and negative values, and simple enough to standardize across machines.

There is no deep cosmic meaning here. A timestamp is a convention, and conventions win when they are boring, stable, and easy to implement. The same idea shows up all over computing: pick a shared origin, then count from there.

If you want a broader refresher on the family of time formats, our guide on epoch timestamps and real-date conversion is the natural next tab.

Why developers keep using Unix time

Unix time solves a bunch of small problems before they turn into annoying ones. Numeric values sort cleanly, compare cleanly, and serialize cleanly in JSON, databases, logs, and APIs. That makes it ideal for anything that needs to answer questions like “which event happened first?” or “how old is this cache entry?”

It also avoids locale traps. Strings like 03/04/2025 can mean different things depending on who is reading them, but a Unix timestamp means the same instant everywhere as long as you interpret it as UTC.

That does not mean Unix time is the perfect format for humans. It is great for systems, bad for eyeballs. Logs, database rows, and API payloads often use timestamps internally, then format them into readable dates only when the result is shown to a person.

Unix time, UTC, and time zones

Unix timestamps are defined in UTC, not local time. That detail matters because a timestamp is not “3 PM in New York” or “8 AM in London”; it is one absolute instant that can be rendered in any timezone. The number does not change when you travel or when daylight saving shifts the clock around.

This is where confusion usually enters the room. A developer stores a timestamp, then formats it with the wrong timezone and gets a date that looks off by several hours. The data was fine; the display layer was lying.

A reliable pattern is to store timestamps in UTC, then convert only at the edge of the system. Databases, APIs, and background jobs can stay on the same page while the UI renders local time for the user.

Common gotchas: seconds, milliseconds, and overflow

One of the most common mistakes is mixing seconds and milliseconds. Many JavaScript APIs use milliseconds since the epoch, while lots of Unix-oriented tools and databases use seconds. If a number suddenly looks 1,000 times too large, that is usually the bug.

Here is the usual shape of the problem in JavaScript:

const seconds = 1735689600;      // 2025-01-01 00:00:00 UTC
const milliseconds = 1735689600000;

console.log(new Date(seconds));         // Wrong for most cases: treated as ms
console.log(new Date(milliseconds));    // Correct

Another thing to watch is timezone formatting. A timestamp like 1735689600 may represent midnight UTC, but your browser may show a different local clock time when it renders that same instant. The underlying moment is the same; only the presentation changes.

There is also the storage question. Most modern systems handle Unix time comfortably, but if you are working with old code or fixed-width integer fields, you can still run into limits. That is one reason developers sometimes prefer 64-bit integers or higher-level date types when the domain demands it.

A Worked Example

Suppose you receive this API payload and need to display the order time to a user:

{
  "order_id": 4815,
  "created_at": 1704067200
}

The number 1704067200 is a Unix timestamp in seconds. It means 2024-01-01 00:00:00 UTC, which is easy for a machine to compare but not especially friendly to read at a glance.

Here is a simple transformation in JavaScript:

const createdAt = 1704067200;
const date = new Date(createdAt * 1000);

console.log(date.toISOString());
// 2024-01-01T00:00:00.000Z

Notice the multiplication by 1000. That converts seconds into milliseconds, which is what JavaScript’s Date constructor expects. Forget that step and you will end up somewhere in January 1970, which is a very specific kind of bug report.

If you want to inspect the raw number in another base or format, the number base converter can help when you are debugging weird-looking values. That is not usually necessary for time work, but it is useful when timestamps show up in logs, IDs, or binary protocols.

How Unix timestamps show up in real systems

You will see Unix time in logs, caches, message queues, database rows, and auth tokens. It is a compact way to say when something happened or when something expires. A token might store an expiry as a Unix timestamp so the server can check it with a plain numeric comparison.

In SQL, the pattern is usually straightforward. You store an integer or a timestamp type, then sort or filter by it:

SELECT id, created_at
FROM events
WHERE created_at > 1735689600
ORDER BY created_at DESC;

In logs, Unix timestamps are handy because they are easy to grep, sort, and difference. If you have two log entries and need to know how far apart they are, subtract one from the other and you get elapsed seconds without extra parsing.

That is the real value of the format. It turns time into a number that systems can do math on without guessing.

Frequently Asked Questions

Is a Unix timestamp always in UTC?

Yes, the standard Unix timestamp is based on UTC. The number itself does not carry a timezone, which is why it can be displayed in different local times without changing the underlying value. If you see a timestamp rendered differently on two machines, the timezone conversion happened during display.

Why do some timestamps have 10 digits and others have 13?

Ten-digit timestamps are usually in seconds, while 13-digit timestamps are usually in milliseconds. The extra three digits come from the smaller unit. If a value looks suspiciously large, check whether the code expects seconds or milliseconds before you start blaming the data.

Can Unix timestamps represent dates before 1970?

Yes, negative Unix timestamps represent moments before the epoch. Support depends on the language, database, or library you are using, but the concept itself allows pre-1970 dates. This is useful when you need to deal with historical records or backfilled data.

What is the difference between Unix time and ISO 8601?

Unix time is a numeric count of seconds since the epoch, while ISO 8601 is a human-readable date/time format like 2025-07-14T12:34:56Z. Unix time is better for storage, sorting, and math. ISO 8601 is better for logs, APIs, and anything a person might need to read without decoding it first.

One Last Thing

The core idea is simple: a Unix timestamp is a universal counter for time, not a calendar format. That is why it starts in 1970, why it uses UTC, and why developers keep reaching for it when they need predictable comparisons instead of friendly-looking strings.

If you are converting values, checking whether a number is in seconds or milliseconds, or just trying to make sense of an ugly timestamp in a log, use the Unix timestamp converter and skip the hand math. It is faster than squinting at epoch math in your head, which is usually where the trouble starts.