Unix Time for Beginners: What a Timestamp Actually Is

If you've ever seen a number like 1798675200 where a date should be, that's Unix time — and once you know the one rule behind it, every confusing timestamp, API response, and log file suddenly makes sense.

What Unix time actually is

Unix time (also called epoch time or POSIX time) is a way of representing a moment by counting seconds instead of writing a date. The count starts at a fixed point called the epoch: January 1, 1970, 00:00:00 UTC. Every Unix timestamp is simply the number of seconds that have passed since that instant. The number 1798675200, for example, doesn't look like a date at all — but run it through a converter and it resolves to a specific calendar date and time, because it's counting, not labeling.

There's nothing magical about 1970. It was chosen by early Unix developers as a convenient round starting point when the operating system was being designed in the early 1970s, and it stuck — every major operating system, programming language, and database still uses it today. A negative timestamp just means a moment before 1970; a timestamp like -86400 is exactly one day earlier, December 31, 1969.

Why software counts instead of writing dates

Calendar dates are awkward for a computer to work with. "March 3rd" isn't a single, comparable value — it depends on what year, what timezone, and whether you're in a leap year. A plain integer count of seconds sidesteps all of that. Two timestamps can be compared with simple math: subtract one from the other and you get an exact duration in seconds, with no calendar logic involved. That's why Unix time shows up everywhere under the hood — in API responses, database columns, log files, cache expiry rules, and session tokens — even though almost no human-facing screen ever displays the raw number. Software converts it to a readable date only at the very last step, right before it reaches a person.

Seconds vs. milliseconds: the most common bug

The single most common Unix time mistake isn't a math error — it's a units mismatch. The original Unix standard counts in seconds, but JavaScript's Date.now() and many modern APIs (including most JSON-based web APIs) count in milliseconds instead, because milliseconds give finer precision for things like measuring page load time. The two formats look almost identical and are easy to confuse:

If a timestamp gets fed into the wrong converter — seconds treated as milliseconds, or vice versa — the resulting date is off by a factor of 1,000, which usually lands somewhere absurd (a date centuries away) rather than just slightly wrong. That "obviously broken" result is actually the easiest version of this bug to catch; the harder one is when a value is off by 1,000x but still lands on a plausible-looking date. The fastest way to check is the digit count: 10 digits means seconds, 13 means milliseconds, for any date in the 2020s and 2030s. CalcPerch's Unix Timestamp Converter detects seconds vs. milliseconds automatically and shows both the local time and UTC side by side, so you don't have to eyeball the digit count yourself.

Unix time and timezones

A Unix timestamp itself has no timezone — it's a single count of seconds since a fixed moment, and that moment is the same instant everywhere on Earth. The timezone only enters the picture when the number gets turned back into a human-readable date, because "what time was it" depends on where you were standing. This is actually one of Unix time's biggest advantages: storing timestamps as raw epoch seconds and converting to local time only for display means a database or log file never has ambiguous or double-counted times around daylight saving changes, which is a real and common bug when systems store local time directly instead.

The Year 2038 problem

Many older systems store Unix time as a signed 32-bit integer, which can only count as high as 2,147,483,647 before it runs out of room and wraps around to a negative number. That ceiling is reached at 03:14:07 UTC on January 19, 2038 — a real limitation known as the Year 2038 problem (or "Y2038"), the Unix-world equivalent of the Y2K bug. Past that instant, a 32-bit signed timestamp overflows and can be misread as a date in 1901 instead of 2038. Most modern systems have already moved to 64-bit timestamps, which push the same ceiling out roughly 292 billion years, but the risk isn't zero — it lives on in older embedded devices, some file systems, and legacy database schemas that were never migrated off 32-bit time fields.

How to work with Unix time yourself

You rarely need to do epoch math by hand, but it helps to know the shape of the problem so you can spot it in the wild: reading a timestamp out of an API response, debugging why a scheduled job fired at the wrong hour, or checking when a file was actually last modified in a system log. CalcPerch's timestamp converter handles the conversion in both directions — paste in a timestamp to get a readable date, or pick a date and time to get the epoch number back out, with the current live timestamp shown for reference. For date math that isn't about a single instant — counting days between two dates, or adding a number of days to a date — the date calculator is the better tool, since it works in calendar terms rather than raw seconds.

Common mistakes to watch for

• Mixing seconds and milliseconds. By far the most frequent bug — check the digit count before trusting a conversion.
• Assuming a timestamp carries timezone info. It doesn't. If a date looks "off by a few hours," the raw number is fine — it's being displayed in the wrong timezone.
• Forgetting leap seconds don't exist in Unix time. Unix time treats every day as exactly 86,400 seconds; when a real leap second is inserted into UTC, most systems simply repeat or skip a second internally rather than reflecting it in the count.
• Hardcoding a 32-bit integer type for a timestamp field in new code — it works fine today but silently breaks in 2038.