Unix Timestamps Explained: Why Computers Count Time in Seconds Since 1970

Quick answer: A Unix timestamp is the number of seconds (sometimes milliseconds) elapsed since midnight, January 1, 1970, UTC, a fixed reference point known as the Unix epoch. Computers use it because a single, ever-increasing number is far simpler to store, compare, and sort than a calendar date broken into year, month, day, and time fields, and because it carries no timezone of its own, it represents the same instant everywhere on Earth.

Dig into an API response, a database column, or a log file, and it's common to find a date represented as a plain number - something like 1798000000 - with no obvious connection to a calendar date at all. That's a Unix timestamp, and once you know what it's actually counting, the format makes a lot more sense than it looks like it should.

What the number is actually counting

A Unix timestamp is the number of seconds that have elapsed since midnight, January 1, 1970, UTC - a fixed reference point called the Unix epoch. Every moment in time, past or future, can be represented as a single number: seconds before or after that reference point. 0 is the epoch itself. A billion seconds later lands in September 2001. There's no month, day, or hour field to parse - just one continuously increasing number.

The epoch as a practical choice, not a technical necessity

Nothing about January 1, 1970 is mathematically special. Any fixed reference date would work exactly as well for the underlying idea of "count elapsed seconds from a known point," since the whole system only needs one thing: everyone agreeing on the same starting line. 1970 was simply convenient during Unix's early development in the late 1960s and early '70s, close enough to the system's creation that early timestamps were small, manageable numbers. It was later formalized as part of the POSIX standard, which is why it's the epoch nearly every modern operating system, database, and programming language still uses today, rather than each one having picked its own.

Why this format won out for computers specifically

Storing a date as a single number is dramatically simpler for a computer to work with than storing a year, month, day, hour, minute, and second as separate fields. Comparing two dates becomes a single numeric comparison instead of a multi-field one. Calculating the time between two events becomes subtraction. Sorting events chronologically is just sorting numbers. None of the calendar complexity - different month lengths, leap years, timezones - has to be reasoned about at all, because none of it is present in the stored value; it only shows up when a timestamp gets converted into something a person reads.

What happens as the number keeps growing

A single ever-increasing number still has to be stored in some fixed amount of space, and that's where the well-known "Year 2038 problem" comes from: a timestamp stored as a 32-bit signed integer can only count up to roughly 2.1 billion seconds past the epoch before it runs out of room and wraps around to a negative number, which lands on January 19, 2038. Systems that store timestamps as 64-bit integers instead, which is the norm for most software written or updated in the last decade or so, push that same ceiling out to a point so far in the future it isn't a practical concern. The risk is concentrated in older or embedded systems that haven't made that jump.

Why the number itself has no timezone

This is the detail that trips people up: a Unix timestamp represents the same instant everywhere on Earth, by design - it's a count of elapsed seconds, not a description of a wall clock reading. "What time is it" at that instant depends entirely on where you are, but "how many seconds have elapsed since the epoch" doesn't - that's the whole reason it's a useful universal format for systems that need to agree on ordering events regardless of where each one happened.

Converting a timestamp without losing the plot

Because the raw number has no timezone, every conversion to a readable date has to supply one from somewhere, either explicitly or by defaulting to whatever timezone the converting system happens to be running in. That default is exactly where a lot of real bugs come from: a server converting a timestamp in UTC and a browser converting the same timestamp in the visitor's local timezone will legitimately display different calendar dates for numbers within a few hours of midnight, and neither one is wrong, they're just answering "what date is this" from two different places on Earth. Time Zone Converter is useful for exactly this kind of check, seeing what a specific moment looks like across several timezones side by side rather than assuming one.

Timestamp Converter goes both directions - a raw Unix timestamp into a readable date, or a date you pick into the timestamp a system actually expects - handling the timezone conversion that turns a universal number into a specific local reading.

Where Unix timestamps actually show up

They're everywhere once you know to look: a database created_at or updated_at column is commonly stored this way for the sorting and comparison reasons above; HTTP caching headers and log files frequently record events as a raw timestamp rather than a formatted date; and JWT access tokens encode their issued-at and expiry times (iat and exp) as plain Unix timestamps, which is why decoding one shows a number rather than a date until something converts it.

Common mistakes worth avoiding

Mixing up seconds and milliseconds. This is by far the most common Unix timestamp bug: passing a millisecond value where a library expects seconds produces a date thousands of years in the future, and passing seconds where milliseconds are expected produces a date sitting right around the epoch itself, January 1, 1970. The digit-count check above (10 digits versus 13) catches this instantly.

Assuming a converted date is "the" date. Since the raw number has no timezone, a converted date is only ever correct for the timezone that was used to convert it. Treating one converted reading as universally correct, rather than as one of several equally valid readings depending on location, is a frequent source of off-by-a-day bugs around midnight boundaries.

Ignoring the storage width for long-lived data. For anything that needs to represent dates far in the future or the deep past, checking whether the underlying storage is 32-bit or 64-bit matters more than it sounds like it should, precisely because of the overflow behavior described above.

The short version

A Unix timestamp is a single number counting seconds since a fixed, arbitrary reference point in 1970 - not because that date matters, but because a single ever-increasing number is far easier for a computer to store, compare, and sort than a calendar date with all of its irregularities. The number has no timezone of its own; that only gets introduced the moment it's converted into something meant to be read. Timestamp Converter and Time Zone Converter together cover both halves of that conversion.