glunty A Unix timestamp is a single number that names an exact moment in time. It looks like 1700000000 and carries no year, month, or timezone on its face. That plainness is the whole point: one integer, agreed on everywhere, that any program can compare, sort, or subtract without parsing a date string. This post explains what that number means, the two units you will meet, why it ignores timezones, the famous Year 2038 problem, and how to convert in both directions.
The Unix epoch: seconds since 1970
The Unix timestamp counts the number of seconds that have elapsed since a fixed reference instant called the epoch. That instant is midnight UTC on 1 January 1970, written 1970-01-01T00:00:00Z. At exactly that moment the timestamp was 0. One second later it was 1, and it has been climbing by one every second since.
So 1700000000 means “1.7 billion seconds after the start of 1970.” Decode it and you get 2023-11-14T22:13:20Z. The number 86400 is exactly one day after the epoch, because a day has 86,400 seconds, which lands you at 1970-01-02T00:00:00Z. Timestamps before 1970 are simply negative: -86400 is the day before the epoch, 1969-12-31T00:00:00Z.
This design is why timestamps are so easy to work with. To find the gap between two events, subtract one number from the other and you have the answer in seconds. No calendar math, no leap-year edge cases, no month lengths.
Seconds versus milliseconds
Here is the single most common source of confusion. The classic Unix timestamp is measured in seconds, but many systems use milliseconds instead. JavaScript is the usual culprit: Date.now() returns milliseconds since the epoch, so the same moment that Python or a database stores as 1700000000 shows up in the browser as 1700000000000.
The tell is length. A seconds timestamp for any date near today has 10 digits. A milliseconds timestamp has 13. If you feed a milliseconds value into a tool expecting seconds, you will land roughly 50,000 years in the future; do the reverse and you land in 1970. When a converted date looks absurdly far off, check whether you mixed up the unit. Some systems go further into microseconds (16 digits) or nanoseconds (19 digits), but seconds and milliseconds cover almost everything you will see.
Why it is timezone-independent
A Unix timestamp does not have a timezone, and that is a feature, not an omission. The count is always measured against UTC, so the number 1700000000 refers to the same physical instant whether you read it in Tokyo, London, or Los Angeles. What changes between those places is only how you choose to display it: 2023-11-14T22:13:20Z in UTC is the same instant as 2023-11-15T07:13:20 in Tokyo and 2023-11-14T14:13:20 in Los Angeles.
This separation is what makes timestamps reliable for storage and messaging. Save the integer, and the question “which timezone was this written in?” never arises. You apply a timezone only at the edges, when a human needs to read the value. To see the same instant rendered across regions, the time zone converter does that translation for you.
The Year 2038 problem
Older software stored the timestamp in a signed 32-bit integer. A signed 32-bit integer can hold values up to 2,147,483,647, and that many seconds after the epoch lands on 2038-01-19T03:14:07Z. One second later the counter overflows, wraps around to a large negative number, and the date jumps back to December 1901. This is the Year 2038 problem, and it is the direct descendant of the Year 2000 problem.
The fix is well understood: store the timestamp in a 64-bit integer instead. A 64-bit signed value pushes the overflow roughly 292 billion years into the future, which is comfortably past any deadline that matters. Most modern languages, databases, and operating systems already use 64-bit time, so the remaining risk lives in old embedded devices and legacy code that nobody has revisited. If you maintain anything that still packs time into 32 bits, 2038 is a real deadline.
How to convert both ways
Going from a timestamp to a readable date means adding the elapsed seconds to the epoch and formatting the result. Going the other way means computing how many seconds a given date sits after 1970-01-01T00:00:00Z. Every language ships helpers for this: datetime.utcfromtimestamp() in Python, new Date(ms) in JavaScript, date -d @1700000000 on the Unix command line.
For quick one-off checks you do not need to open an editor. Paste a number or pick a date in the Unix timestamp converter and it shows the result instantly, in both seconds and milliseconds, with the UTC value spelled out so you can confirm the unit at a glance. That is often faster than remembering which function your current language uses.
The takeaway
A Unix timestamp is just seconds since the start of 1970 in UTC, which makes it a compact, unambiguous, timezone-free way to pin down a moment. Watch the unit so you do not confuse seconds with milliseconds, remember that display timezones are applied only at the edges, and keep 64-bit storage in mind so 2038 stays a non-event. With those three habits, timestamps become one of the least surprising things in software.