Unix Timestamp Explained: Convert Epoch Time
A Unix timestamp is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, a starting point known as the Unix epoch. The timestamp 1735689600 is midnight at the start of 1 January 2025 in UTC, and 1700000000 is 14 November 2023 at 22:13:20 UTC. Once you know the epoch and the unit — seconds, milliseconds, or something finer — any timestamp turns into a date with one division.
What exactly is a Unix timestamp?
A Unix timestamp, also called epoch time, is a single integer that counts time from a fixed starting point instead of writing out a year, month, day, and time. That starting point, the epoch, is midnight at the beginning of 1 January 1970 in Coordinated Universal Time (UTC). Every second after that moment adds one to the count, so the timestamp is simply a running total of seconds. The timestamp 0 is the epoch itself, and a timestamp of 60 is one minute later, at 00:01:00 UTC on 1 January 1970.
Counting from one fixed point has a practical payoff: dates become ordinary numbers. Comparing two moments is comparing two integers, finding the gap between them is subtraction, and sorting events is sorting numbers. A calendar date, by contrast, needs month lengths, leap years, and time zones before any of that works. That is why databases, log files, APIs, and file systems so often store time as a timestamp and only turn it into a readable date when a human needs to see it.
Two details of the definition catch people out. First, a timestamp has no time zone built in. It always means the same instant everywhere on Earth; time zones only appear when software renders that instant as local clock time. Second, Unix time treats every day as exactly 86,400 seconds and does not insert leap seconds, so it can drift by a few seconds from strict astronomical time over decades. For nearly all everyday software, that difference is invisible, but it is worth knowing if you work with precise scientific timekeeping.
Timestamps can also be negative. A negative value counts seconds before the epoch, so -86400 is 31 December 1969 at 00:00:00 UTC. Negative timestamps are rare in modern logs, but they appear in historical data and in any system that records dates before 1970, and a converter that rejects them is hiding valid dates rather than protecting you.
How do you read a timestamp at a glance?
The fastest clue to a timestamp's unit is its length. A current timestamp in seconds has 10 digits, because the count passed one billion in September 2001 and will not reach ten billion until the year 2286. A current timestamp in milliseconds has 13 digits, because it is the same count multiplied by 1,000. Finer units add more digits still, as the table shows.
| Digits | Unit | Same instant as 1735689600 | Common source |
|---|---|---|---|
| 10 | Seconds | 1735689600 | Python time.time(), Go time.Unix() |
| 13 | Milliseconds | 1735689600000 | JavaScript Date.now(), Java System.currentTimeMillis() |
| 16 | Microseconds | 1735689600000000 | Some databases and high-resolution timers |
| 19 | Nanoseconds | 1735689600000000000 | Go time.UnixNano(), hardware clocks |
The timestamp converter accepts a value in any of these units and shows the matching date, so you rarely need to convert by hand. Still, the digit rule is a useful sanity check before you paste a number anywhere: if a timestamp has 13 digits and you expected seconds, divide by 1,000 first. If it has 10 digits and a tool expects milliseconds, multiply by 1,000. Most "wrong date" complaints about timestamps turn out to be this one mix-up, not a broken converter.
Worked example: convert 1735689600 to a date
Take the timestamp 1735689600 and work out what date it is, using only arithmetic and a calendar.
Step 1 — split into days and seconds. One day has 86,400 seconds, so divide: 1735689600 / 86400 = 20089 exactly, with a remainder of 0. The timestamp is therefore exactly 20,089 days after the epoch, at midnight UTC, since a zero remainder means no extra hours, minutes, or seconds.
Step 2 — turn days into years. Fifty-five years contain 55 x 365 = 20075 ordinary days, plus one extra day for each leap year in the span. Between 1970 and 2025 there are 14 leap years (1972, 1976, 1980, 1984, 1988, 1992, 1996, 2000, 2004, 2008, 2012, 2016, 2020, and 2024), giving 20075 + 14 = 20089 days. So 20,089 days after 1 January 1970 is 1 January 2025.
Step 3 — read off the answer. The timestamp 1735689600 is 1 January 2025 at 00:00:00 UTC. In a time zone ahead of UTC, the same instant falls later on the clock — 08:00 in Shanghai, for instance — but the date in UTC is 1 January.
The reverse direction works the same way. To find the timestamp for 1 January 2026, count 56 years from the epoch: 56 x 365 = 20440 days, plus the same 14 leap days, giving 20454 days. Multiply by 86,400 and the answer is 1767225600. Check it with the timestamp converter and you will get the same figure, which confirms the arithmetic in both directions.
Why do programmers store time this way?
Three properties make epoch time hard to beat for storage. It is compact: one integer replaces a whole date string. It is unambiguous: there is no argument about whether 03/04 means 3 April or March 4, and no daylight saving transition that makes one local hour happen twice or not at all. And it makes arithmetic trivial: adding 86,400 moves exactly one day forward, and subtracting two timestamps gives the gap in seconds, which converts cleanly to minutes, hours, or days.
That last point matters most around daylight saving changes. If you add "one day" to a local clock time across a spring-forward transition, a naive calculation can land an hour early or late, because that day only had 23 hours. Adding 86,400 seconds to a timestamp always lands on the same UTC time the next day, and the display layer then converts it to whatever the local clock says. Keeping storage in UTC timestamps and converting only for display sidesteps a whole class of bugs that only show up twice a year.
Seconds or milliseconds? The most common mistake
Almost every timestamp bug in practice is a unit mismatch, and the symptoms are distinctive enough to diagnose at sight. Feed a 13-digit milliseconds value into a converter that expects seconds, and you get a date tens of thousands of years in the future — because the tool treats each millisecond as a whole second. Feed a 10-digit seconds value into a field that expects milliseconds, and you get a date in January 1970, because 1,735,689,600 milliseconds is only about 20 days after the epoch, landing on 21 January 1970.
The mismatch is easy to create because different languages choose different defaults. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds, while Python's time.time() returns seconds with a fractional part, and Go offers both through Unix() and UnixMilli(). Whenever you move a timestamp between systems, check the unit at both ends before assuming either side is wrong. A quick check with a known value settles it: 0 must give the epoch, 1000000000 must give 9 September 2001 at 01:46:40 UTC, and 1735689600 must give 1 January 2025.
What is the Year 2038 problem?
On 19 January 2038 at 03:14:07 UTC, a signed 32-bit integer holding seconds since the epoch reaches its largest possible value, 2,147,483,647. One second later it wraps around to a large negative number, which software would read as a date in December 1901. This is the Year 2038 problem, the 32-bit cousin of the Year 2000 problem.
Modern 64-bit systems are not affected: a signed 64-bit seconds counter runs for roughly 292 billion years before overflowing. The risk sits in older embedded systems, industrial controllers, and file formats that still store time in 32 bits, and in any code that truncates a 64-bit timestamp down to 32 bits on its way through. If you maintain such a system, the fix is to widen the field and test with dates past 2038 now, while there is still time to find the places that assumed 32 bits was enough.
Practical tips
- State the unit every time. Write "seconds" or "milliseconds" next to any timestamp in documentation, logs, and API fields. A bare integer invites exactly the mix-up described above.
- Store UTC, display local. Keep timestamps as UTC epoch values in storage, and convert to the viewer's time zone only when rendering. Never store a local clock reading and hope the time zone is remembered alongside it.
- Test with known values. Before trusting a converter or a piece of date code, check 0, 1000000000, and 1735689600. If any of those comes back wrong, the unit or the time zone handling is off.
- Do date arithmetic on timestamps, not on strings. Adding days, comparing deadlines, and sorting events all work cleanly on integers; doing them on formatted dates invites month-length and daylight saving errors.
- Keep nanoseconds out of floating-point numbers. A 64-bit float holds millisecond timestamps exactly, but a 19-digit nanosecond value loses precision when stored as a float. Use integers or big-integer types for nanosecond data.
- Watch out for dates before 1970. Negative timestamps are valid, but some converters and databases reject them or treat them as errors. Test a pre-1970 date explicitly if your data includes one.
Try it yourself
Paste any timestamp to see its date and time in UTC and your local time zone — everything runs locally in your browser, nothing is uploaded.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. It is a single integer with no time zone, no daylight saving adjustment, and no formatting, which is why software uses it to store and compare moments in time. The timestamp 1735689600, for example, means exactly midnight at the start of 1 January 2025 in UTC.
How do I convert a Unix timestamp to a date?
Divide the timestamp by 86,400 to get whole days since the epoch, and use the remainder for the time of day. The timestamp 1735689600 divides into exactly 20,089 days with no remainder, so it is midnight UTC, and 20,089 days after 1 January 1970 is 1 January 2025. In practice, use a converter or a date library rather than doing this by hand, and always check whether the result is shown in UTC or in your local time zone.
What is the difference between seconds and milliseconds timestamps?
A seconds timestamp has 10 digits and counts seconds since the epoch, while a milliseconds timestamp has 13 digits and counts thousandths of a second. JavaScript's Date.now() returns milliseconds, while Python's time.time() returns seconds as a decimal. Feeding a 13-digit value into a seconds converter gives a date tens of thousands of years in the future, and feeding a 10-digit value into a milliseconds converter gives a date in January 1970.
Why does a timestamp have 10 or 13 digits?
The digit count tells you the unit. Ten digits means seconds, 13 means milliseconds, 16 means microseconds, and 19 means nanoseconds. Current seconds timestamps start with 1 and have 10 digits, and current milliseconds timestamps start with 1 and have 13 digits. If a value looks roughly a thousand times too large or too small for the date you expect, the unit is almost certainly wrong, not the date itself.
What happens in the year 2038?
On 19 January 2038 at 03:14:07 UTC, a signed 32-bit counter reaches its maximum value of 2,147,483,647 and then wraps around to a negative number, which software would read as a date in December 1901. This is the Year 2038 problem. Modern 64-bit systems store timestamps in 64 bits and are not affected, but old embedded systems and old file formats that still use 32-bit time need updating before that date.
Are Unix timestamps affected by time zones?
No. A Unix timestamp always refers to the same instant, wherever you are, because it is defined against UTC. Time zones only enter the picture when the timestamp is displayed as a readable date and time: the same timestamp is midnight in London, 01:00 in Berlin, and 08:00 in Shanghai. That is why the safe habit is to store timestamps and convert them to local time only at the moment of display.