What Is a Unix Timestamp? A Complete Guide With Examples
A Unix timestamp is the number of seconds that have passed since January 1, 1970, 00:00:00 UTC, a moment known as the Unix epoch. It’s a single integer, like 1700000000, that represents an exact point in time with no separate date, time, or timezone fields to parse.
What a Unix timestamp actually is
Every Unix timestamp counts elapsed seconds from the same fixed starting point: midnight UTC on January 1, 1970. That instant is second 0. A moment an hour later is 3600. A moment one day later is 86400. There’s no month, day, or hour baked into the number itself, just a running count.
Computers lean on this format for a few practical reasons. A single integer is far more compact than a formatted string like 2023-11-14T22:13:20Z, and it’s trivial to compare, sort, or do arithmetic on. Working out whether one event happened before another is a matter of comparing two integers instead of parsing two strings and reasoning about calendars. Adding “7 days” to a timestamp is just adding 604800 (7 × 86400) to a number, no leap-year or month-length logic required. And because the count is anchored to UTC, a timestamp means the same instant everywhere on Earth, regardless of which timezone produced it or which timezone reads it back. That’s exactly why a database created_at column, a cron schedule, or a JWT exp claim so often stores a plain integer instead of a formatted date.
Worked example: reading real timestamp values
Here are five timestamp values and the UTC date and time each one represents:
| Unix timestamp (seconds) | UTC date and time |
|---|---|
| 0 | January 1, 1970, 00:00:00 UTC (the epoch itself) |
| 1000000000 | September 9, 2001, 01:46:40 UTC |
| 1700000000 | November 14, 2023, 22:13:20 UTC |
| 2000000000 | May 18, 2033, 03:33:20 UTC |
| 2147483647 | January 19, 2038, 03:14:07 UTC |
Take 1700000000 as an example of how these line up. One billion seconds after the epoch lands on September 9, 2001. Another 700 million seconds, roughly 22 years, lands you in November 2023. You don’t need to do that division by hand to trust the table, but it’s a useful sanity check: each jump of 1,000,000,000 seconds corresponds to about 31.7 years, so if you ever see a timestamp and want a rough gut-check on the year, dividing by that figure gets you close before you reach for a tool.
The last row is worth remembering on its own: 2147483647 is the highest value a 32-bit signed integer can hold, and it lands on January 19, 2038. More on why that matters below.
Seconds or milliseconds? Telling them apart
This is the single most common Unix timestamp mistake, and it’s easy to catch once you know the trick: count the digits. A timestamp in seconds has 10 digits today, like 1700000000. The same instant in milliseconds has 13 digits, 1700000000000, three extra zeros because a millisecond is one-thousandth of a second.
The two conventions coexist because different tools default to different units. JavaScript’s Date.now() and most browser and Node.js APIs return milliseconds. Unix system calls, cron, log file timestamps, and most command-line and server-side tooling use seconds. If you paste a millisecond value into a field expecting seconds, the tool multiplies your intended date by 1000, and you’ll land somewhere around the year 55000, comfortably past any date picker’s useful range. The reverse mistake, seconds parsed as milliseconds, does the opposite: it collapses a real date down to sometime in 1970. If a converted date looks obviously wrong, in the far future or stuck near the epoch, check the digit count first.
Convert a timestamp to a date
If you’re staring at a raw integer in an API response or a log line and need to know what it actually means, paste it in below. It handles both seconds and millisecond values automatically.
Convert a date to a timestamp
The reverse case comes up just as often: you’ve picked a specific date and time, maybe to schedule a cron job or set an expiry, and you need the timestamp to pass into an API or config file.
Common mistakes and edge cases
Mixing up seconds and milliseconds. As covered above, this is the mistake that trips up developers most often. A 10-digit value is seconds, a 13-digit value is milliseconds. Get this backwards and your date lands either in 1970 or tens of thousands of years from now.
The Year 2038 problem. Older systems that store a Unix timestamp as a 32-bit signed integer can only count up to 2147483647, which corresponds to January 19, 2038, 03:14:07 UTC. One second past that, the value overflows and wraps around to a large negative number, which many programs then misinterpret as a date back in December 1901. This isn’t a theoretical concern; it’s the same category of bug as the Y2K problem, just with a different rollover point. Modern systems that use a 64-bit integer for timestamps don’t have this ceiling; their range extends billions of years into the future.
Assuming a timestamp carries a timezone. It doesn’t. A Unix timestamp is an absolute instant in time, nothing more. The confusion people run into isn’t in the timestamp itself, it’s in how it gets displayed. Two people in different timezones looking at the exact same timestamp, say 1700000000, will see different local clock times (one might read 22:13 while the other reads 14:13), but they’re both looking at the same instant. When a date looks “wrong,” it’s almost always a display or conversion issue, not a problem with the underlying value.
Negative timestamps and dates before 1970. Seconds don’t have to count forward only. A negative Unix timestamp represents a date before the epoch: -86400, for instance, is December 31, 1969, exactly one day before second 0. This is mathematically valid and many libraries handle it fine, but not every system or tool accepts negative values, so treat pre-1970 dates as worth double-checking if you’re integrating with an older API or database column.
Frequently asked questions
What is a Unix timestamp?
It’s the number of seconds elapsed since January 1, 1970, 00:00:00 UTC, also called the Unix epoch. It’s a plain integer, like 1700000000, that represents one specific instant in time without needing a separate date, time, or timezone field.
How do I know if my timestamp is in seconds or milliseconds?
Count the digits. A 10-digit value, such as 1700000000, is in seconds. A 13-digit value, such as 1700000000000, is the same instant in milliseconds. If a converted date looks absurdly far in the future, you likely have milliseconds and are treating them as seconds.
What is the Year 2038 problem?
It’s an overflow bug affecting systems that store Unix timestamps as 32-bit signed integers. The maximum value such an integer can hold is 2147483647, which corresponds to January 19, 2038, 03:14:07 UTC. Past that point, the value wraps to a large negative number, which can corrupt date calculations. 64-bit systems, now the norm, aren’t affected for practical purposes.
Can I convert a date before 1970?
Yes. Dates before the epoch are represented as negative Unix timestamps. December 31, 1969, for example, is -86400. Most modern tools and libraries support negative values correctly, though it’s worth confirming if you’re working with an older system.
Why do databases store dates as Unix timestamps instead of a date string? An integer is compact, sorts and compares instantly, and supports simple arithmetic (adding a number of seconds to shift a date) without any calendar logic. It’s also timezone-independent by nature, since it always refers to UTC, so a stored value means the same instant regardless of where it’s read back. Converting to a human-readable, localized string is left for the moment you actually display it.