What Is a Unix Timestamp? Converting Epoch Time Without the Headache

What Is Unix Timestamp? Easy Guide to 10 vs 13 Digits

by

You open an API response and see 1735689600 where a date should be. Wondering what is unix timestamp? You are asking the right question. You check a log file and spot 1700000000000. You paste one of these numbers into an online tool and get a date in the year 55840. None of this means you broke anything — it means you have met the Unix timestamp, one of computing’s most useful and most confusing numbers. This unix timestamp converter explained guide walks through what epoch time actually counts, why timestamps come in two different lengths, why the same number can show two different dates, and how to convert unix timestamps to dates without the headache.

The short version: a Unix timestamp is simply the number of seconds that have passed since 00:00:00 UTC on 1 January 1970. That moment — midnight on New Year’s Day 1970 in Greenwich, England — is called the epoch, and every second since then gets its own number. Right now, the current timestamp is about 1790431332, the number of seconds between the epoch and 14:02 UTC on 26 September 2026. By the time you finish this page, it will be a little higher, ticking up once per second. That sentence is the whole answer to what is unix timestamp, stripped of jargon.

Table of Contents

What Is Unix Timestamp, Exactly?

A unix timestamp explained in plain language is this: computers are bad at storing dates the way humans write them. “Tuesday, November 14th, 2023, at 10:13 PM” is friendly to read but awkward to sort, compare, or do arithmetic on. So in the early days of the Unix operating system, engineers picked a fixed reference point and decided that every moment in time would be recorded as a single integer: the count of seconds since that reference point. That reference point is the epoch — 0 means exactly 1970-01-01 00:00:00 UTC, a Thursday. Computers count seconds; humans read calendars — what is unix timestamp but the bridge between them?

Here are some real, verified conversions so you can see the pattern. Each was computed directly, not guessed: Real numbers, computed directly: the fastest way to internalize what is unix timestamp.

  • 0 → 1970-01-01 00:00:00 UTC (the epoch itself)
  • 1000000000 → 2001-09-09 01:46:40 UTC (the famous “billion seconds” moment)
  • 1609459200 → 2021-01-01 00:00:00 UTC
  • 1700000000 → 2023-11-14 22:13:20 UTC
  • 1735689600 → 2025-01-01 00:00:00 UTC
  • 1767225600 → 2026-01-01 00:00:00 UTC

Notice something neat: clean round numbers like 1735689600 almost always land on exact midnight, because they were chosen as reference points. Real-world timestamps usually look messier — 1700000000 resolves to 22:13:20, not a round hour — because they capture the exact second something happened. Spotting that pattern means you already understand what is unix timestamp at a glance.

The idea proved so practical that it spread far beyond Unix. Today, databases, APIs, log files, session tokens, and file systems across every platform use epoch-based time. Wikipedia’s article on Unix time documents how this convention became a de facto standard even in systems that never ran Unix. Databases, logs, tokens, file systems — everywhere you look, the answer to what is unix timestamp is ‘the standard way to store time’.

10-Digit vs 13-Digit Timestamps: Seconds vs Milliseconds

This is the number-one source of confusion for beginners, and it is the reason most “why is my date wrong?” debugging sessions happen. There are two common flavors of timestamp: Seconds versus milliseconds: the question that follows what is unix timestamp in every debugging session.

  • 10-digit timestamps count seconds since the epoch. This is the classic Unix timestamp. Examples: 1700000000 (2023-11-14 22:13:20 UTC), 1735689600 (2025-01-01 00:00:00 UTC).
  • 13-digit timestamps count milliseconds since the epoch. JavaScript’s Date.now() returns these, so they are everywhere in web development. Examples: 1700000000000 (2023-11-14 22:13:20 UTC — the same moment as 1700000000), 1727700000000 (2024-09-30 12:40:00 UTC).

How to tell which one you have

Count the digits. If the number is 10 digits long and starts with 1, it is almost certainly seconds. If it is 13 digits long, it is almost certainly milliseconds. For a quick sanity check, any correct current timestamp in seconds today begins with 17 or 18, while a millisecond one begins with 17 or 18 followed by eleven more digits — in other words, it looks like the seconds version with three extra digits tacked on the end. Ten digits, seconds; thirteen, milliseconds — the one rule that makes what is unix timestamp click.

The classic mistake is feeding a 13-digit millisecond value into a converter that expects seconds. I did this on purpose to show you what happens: 1700000000000 interpreted as seconds gives you 55840-11-08 — a date more than fifty thousand years in the future. If your converter ever spits out a year with five digits, you are looking at milliseconds. The fix is simple: divide by 1000 (or just drop the last three digits) to get seconds. Going the other way, multiply a seconds timestamp by 1000 to get milliseconds. Year 55840 is the unmistakable symptom of misunderstanding what is unix timestamp length.

Converting milliseconds to seconds, step by step

  1. Take your 13-digit value, for example 1735689600000.
  2. Divide by 1000: 1735689600000 / 1000 = 1735689600.
  3. Convert 1735689600 as seconds → 2025-01-01 00:00:00 UTC. Verified.

The Unix Timestamp Converter handles both lengths automatically — paste either a 10-digit or a 13-digit value and it detects which one you gave it, so the year-55840 problem never happens. Paste either length and it detects which — a practical shortcut once you know what is unix timestamp.

The Same Timestamp, Two Different Dates: UTC vs Local Time

Here is the second big gotcha. A Unix timestamp has no timezone in it. It counts seconds from a UTC reference point, so the timestamp itself is absolute — but when you display it as a human-readable date, the result depends on which timezone you display it in. The same timestamp shows different wall-clock times in different cities. No timezone inside the number: the second half of what is unix timestamp.

Take 1609459200. In UTC that is exactly 2021-01-01 00:00:00 — midnight on New Year’s Day. But display the very same timestamp in other zones and you get: One instant, three wall-clock readings — the cleanest demonstration of what is unix timestamp.

  • UTC: 2021-01-01 00:00:00
  • Karachi (PKT, UTC+5): 2021-01-01 05:00:00
  • New York (EST, UTC-5): 2020-12-31 19:00:00 — still the previous year

All three are correct. The timestamp describes one instant; wall clocks disagree on what to call it. This is why timestamps stored in databases are almost always in UTC, and conversion to local time happens at display time. It is also why debugging “the date is off by a few hours” almost always turns out to be a timezone issue, not a timestamp issue. Unsure which zone a converted date is in? A good converter tells you explicitly. Ours shows both UTC and your local time side by side, and if you need to compare zones directly, the Time Zone Converter handles the arithmetic for you. Store the instant, format for the viewer: the takeaway from what is unix timestamp.

Where You’ll Meet Timestamps in the Wild

Once you know what to look for, you will see epoch timestamps everywhere: Fluency starts here: after this guide, what is unix timestamp will never confuse you in the wild.

  • APIs and JSON responses. Many APIs return dates as timestamps because a number is unambiguous and compact. A response like {"created_at": 1700000000} means the record was created at 2023-11-14 22:13:20 UTC. If you work with API data, our explainer on what a JSON formatter does pairs well with this — timestamps usually arrive buried inside JSON.
  • Databases. Storing dates as integers makes sorting and range queries fast and timezone-free. A WHERE created_at > 1735689600 clause means “everything created after New Year 2025.”
  • Log files. Servers log events with epoch timestamps so entries from machines in different timezones still sort correctly.
  • JWTs and session tokens. The exp (expiry) and iat (issued-at) claims in a JSON Web Token are Unix timestamps. If a token says exp: 1735689600, it expired at the start of 2025. (Tokens are often signed for integrity — see what a SHA-256 hash is for how that signing works.)
  • File metadata. Your operating system records when files were created and modified as epoch values under the hood.
  • Scheduled tasks and caches. “Expire this cache entry 3600 seconds from now” is stored as now + 3600, a simple integer addition no date library required.

Unix Timestamp Explained With Worked Examples

Let us put it all together with a batch of conversions you can check yourself. Every one of these was computed with the system clock in UTC: Check them yourself — verifying is believing when learning what is unix timestamp.

  • 1000000000 → 2001-09-09 01:46:40 UTC
  • 1609459200 → 2021-01-01 00:00:00 UTC
  • 1700000000 → 2023-11-14 22:13:20 UTC
  • 1767225600 → 2026-01-01 00:00:00 UTC
  • 1700000000000 (ms) → 2023-11-14 22:13:20 UTC
  • 1727700000000 (ms) → 2024-09-30 12:40:00 UTC

And going the other direction — date to timestamp — the current moment (14:02:12 UTC on 26 September 2026) converts to 1790431332, which you can verify by converting it back. Notice that the millisecond and second versions of the same moment agree: 1700000000000 and 1700000000 both land on 2023-11-14 22:13:20 UTC. That agreement is a handy self-check whenever you convert by hand.

If you need to do date arithmetic on the results — say, how many days passed between two timestamps — convert them first, then use the Date Calculator to find the difference. The two tools complement each other: the converter turns the number into a date, and the calculator works with the dates. Convert first, calculate second: the workflow once you grasp what is unix timestamp.

A Quick Note on the Year 2038 Problem

Classic Unix timestamps were stored as 32-bit signed integers, and the largest value such an integer can hold is 2147483647. That timestamp corresponds to 2038-01-19 03:14:07 UTC — one second later, the counter overflows. This is the famous Year 2038 problem, and it is the reason modern systems use 64-bit integers for time. A 64-bit timestamp can represent dates billions of years in either direction, so for anything you build today, the practical takeaway is simply: store timestamps in 64-bit fields and you will never think about this again. A 32-bit limit with a famous expiry date — the historical footnote to what is unix timestamp.

Try It: Convert Epoch Time in Your Browser

Reading about timestamps is useful; experimenting with them is better. The Unix Timestamp Converter lets you paste any 10-digit or 13-digit value and instantly see the date in UTC and in your local timezone, or go the other way and turn a date into its timestamp. It auto-detects seconds vs milliseconds, so the year-55840 mistake from earlier cannot happen. Everything runs in your browser — your values are never uploaded to our servers — so you can safely paste timestamps from your own logs and tokens while you learn. Ten minutes of experimenting teaches what is unix timestamp better than any definition.

Try these right now: paste 0 for the epoch, 1000000000 for the billion-seconds milestone, or 2147483647 to see the 2038 limit. Then convert today’s date back into a timestamp and confirm it starts with 17 or 18 — a handy sanity check for any timestamp you meet.

Frequently Asked Questions

What is a Unix timestamp in simple terms?

It is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment called the epoch. For example, the timestamp 1735689600 means exactly 1,735,689,600 seconds after the epoch, which works out to 2025-01-01 00:00:00 UTC. It is a compact, timezone-free way for computers to record a moment in time. Short version restated: that count is what is unix timestamp, full stop.

What is the difference between a 10-digit and a 13-digit timestamp?

A 10-digit timestamp counts seconds since the epoch (the classic Unix timestamp), while a 13-digit timestamp counts milliseconds (common in JavaScript, where Date.now() returns milliseconds). The two represent the same moments: 1700000000 and 1700000000000 both mean 2023-11-14 22:13:20 UTC. Divide a millisecond timestamp by 1000 to get seconds.

Why does my timestamp convert to the wrong date?

The two usual causes are mixing up seconds and milliseconds (a 13-digit value read as seconds gives absurd years like 55840), and timezone confusion (the same timestamp displays as different dates in different zones — for instance, 1609459200 is 2021-01-01 in UTC and Karachi but 2020-12-31 in New York). Check the digit count first, then check which timezone the converter is displaying.

Are Unix timestamps always in UTC?

Yes — the count is defined relative to the epoch at 00:00:00 UTC, so the number itself has no timezone attached. Timezones only enter the picture when you convert the number into a human-readable date. Storing in UTC and converting at display time is the standard practice because it keeps every timestamp unambiguous.

What happens in the year 2038?

On 2038-01-19 03:14:07 UTC, the maximum 32-bit signed integer (2147483647) is reached, and older systems storing timestamps in 32 bits will overflow. Modern systems use 64-bit integers, which pushes the limit billions of years out. If you are building something new, use 64-bit time fields and this is a non-issue. Mark the date: 2038-01-19 is when the oldest systems run out of what is unix timestamp headroom.

How do I convert a Unix timestamp to a date quickly?

Paste the number into an epoch time converter — it will show you the date in UTC and your local timezone, and auto-detect whether you gave it seconds or milliseconds. For a one-off check on your own machine, the command date -u -d @1735689600 on Linux prints 2025-01-01 00:00:00 UTC.