Behind almost every date you see on a screen is a single, unglamorous number: the Unix timestamp. It is how computers actually store time, and understanding it explains a lot — why timestamps are sometimes 10 digits and sometimes 13, why they are always in UTC, and why a real deadline looms in 2038. This article covers all of it.
Convert any timestamp to a human date (and back) with the Unix Timestamp Converter.
Counting from 1970
A Unix timestamp is simply the number of seconds elapsed since a fixed reference instant — midnight UTC on 1 January 1970, known as the Unix epoch. That date was chosen by the creators of the Unix operating system as a convenient recent zero point. Every moment since is a count up from there; moments before it are negative.
So the timestamp 1749686400 is “1,749,686,400 seconds after the start of 1970,” which works out to a specific instant in 2025. The number looks opaque to humans but is perfect for machines.
Why a single number is so useful
Representing time as one integer makes the hard parts easy, as covered in Understanding Dates & Time:
- Unambiguous — there is exactly one timestamp for any instant, with no format or time-zone confusion.
- Comparable — to find which of two events came first, just compare the numbers; bigger is later.
- Easy arithmetic — the seconds between two events is plain subtraction. One day is 86,400 seconds; one hour is 3,600.
- Compact — a single integer stores in a database far more efficiently than a formatted string.
Seconds vs. milliseconds: the 10 vs 13 digit trap
There are two common scales, and mixing them is a frequent bug:
| Digits | Unit | Used by |
|---|---|---|
| ~10 | Seconds | Unix/Linux, most databases, PHP, Python |
| ~13 | Milliseconds | JavaScript, Java |
Always UTC, never local
A crucial property: a Unix timestamp carries no time-zone information — it is an absolute instant, implicitly in UTC. It does not know or care where the user is. You attach a time zone only at the moment you convert it into a human-readable date for display. This is exactly why timestamps are the recommended way to store time: they sidestep the entire time-zone mess until presentation. (More on zones in Time Zones & UTC.)
The Year 2038 problem
Here is the catch built into the original design. Many older systems store the timestamp in a signed 32-bit integer, which can hold values up to about 2.1 billion. Count seconds from 1970 and that ceiling arrives at 03:14:07 UTC on 19 January 2038. One second later, the number overflows and wraps around to a large negative value — flinging the date back to 1901.
This is the “Year 2038 problem,” a smaller cousin of Y2K. The fix is straightforward and already widespread: store the timestamp in a 64-bit integer, which pushes the limit roughly 292 billion years into the future. Modern operating systems, languages and databases have largely moved to 64-bit time, but legacy systems and embedded devices remain a real concern for the next decade.
In practice
The Unix timestamp is the quiet foundation of computer timekeeping: one integer, counting seconds from 1970, always in UTC. Remember the seconds-versus-milliseconds distinction and that the value is zone-free, and timestamps become the cleanest way to store and compare moments. Convert between timestamps and dates with the Unix Timestamp Converter, and see the bigger picture in Understanding Dates & Time.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds that have elapsed since midnight UTC on 1 January 1970 (the "Unix epoch"). It is a single integer that represents an exact moment in time, used by computers, databases and APIs because it is unambiguous and easy to compare or subtract.
Why does my timestamp have 13 digits instead of 10?
A 10-digit timestamp counts seconds; a 13-digit one counts milliseconds (seconds × 1000). JavaScript, for instance, uses milliseconds. If a converted date is wildly wrong (year 50000+ or 1970), you have probably mixed up the two — divide or multiply by 1000.
What is the Year 2038 problem?
Systems that store the timestamp in a signed 32-bit integer can only count up to 03:14:07 UTC on 19 January 2038, after which the number overflows and wraps to a negative value, breaking the date. The fix is to use 64-bit integers, which most modern systems already do.
Is a Unix timestamp in any time zone?
No — a Unix timestamp is always UTC by definition. It represents an absolute instant with no time-zone information attached. You apply a time zone only when converting it to a human-readable local date and time.
How do I convert a Unix timestamp to a readable date?
Feed it to a date function that interprets seconds (or milliseconds) since the epoch, then format it in the time zone you want to display. Most languages have a built-in: from a timestamp you get a date object, which you then format. A converter tool does the same thing instantly without writing code.
Why do timestamps count from 1970?
It is simply the zero point the creators of the Unix operating system chose — a convenient recent date when the system was being designed in the early 1970s. There is nothing special about the date itself; what matters is that everyone agrees on the same starting point so the numbers line up everywhere.
Can a Unix timestamp be negative?
Yes. Moments before the 1970 epoch are represented as negative numbers — counting seconds backward from the zero point. So a date in 1965 has a negative timestamp. Not every system handles negative timestamps gracefully, so very old dates can be a source of bugs.