A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC — known as the Unix epoch. It's the universal language of time in programming, APIs, databases, and security tokens. If you work with 2FA, JWTs, or any token-based authentication, you'll encounter Unix timestamps constantly.
In This Guide
What Is a Unix Timestamp?
Unix time counts seconds continuously from the Unix epoch — January 1, 1970 at midnight UTC. As of early 2026, the current Unix timestamp is around 1,741,651,200. This simple integer is timezone-agnostic and unambiguous, which is why it became the standard way to represent time in computing.
One key property: Unix time doesn't care about timezones. 1,741,651,200 means the same instant everywhere in the world. This makes it ideal for systems where servers, clients, and databases are in different timezones.
Why TOTP Depends on Unix Time
TOTP (Time-based One-Time Password) uses Unix timestamps as one of its two inputs (the other being the secret key). The algorithm divides the current timestamp by 30 to produce a "time window" number. For example, timestamp 1,741,651,200 ÷ 30 = window 58,055,040. Every second within the same 30-second window produces the same TOTP code.
Both your authenticator app and the authentication server calculate this window independently. If their clocks differ by more than ~30 seconds, the windows won't match, and your codes will be rejected. This is why clock sync issues cause TOTP failures.
You can see the live TOTP window alongside timestamps using our Unix Timestamp Converter.
Unix Timestamps in JWTs
JSON Web Tokens (JWTs) use Unix timestamps for three standard claims: iat (issued at — when the token was created), exp (expires — when the token becomes invalid), and nbf (not before — the earliest time the token is valid). All three are Unix timestamps in seconds.
A JWT with "exp": 1741737600 will be rejected by the server after that Unix timestamp. Use our timestamp converter to decode when any JWT expires, or use the JWT Decoder to inspect the full payload.
Converting Timestamps
In JavaScript: Date.now() returns milliseconds — divide by 1000 and round down to get seconds. new Date(timestamp * 1000) converts a seconds timestamp back to a Date object.
In Python: import time; time.time() returns a float of seconds. datetime.utcfromtimestamp(ts) converts back to a datetime.
In the terminal: date -d @1741651200 (Linux) or date -r 1741651200 (macOS) converts a timestamp to a human-readable date. Or just use our browser-based converter.
Common Pitfalls
Seconds vs milliseconds confusion is the most common bug. JavaScript's Date.now() returns milliseconds (13 digits in 2026). Most APIs and security standards expect seconds (10 digits). Mixing these causes tokens that appear to expire 1000x too fast or not at all.
Timezone mistakes: Unix timestamps are always UTC. Converting to a local time is a display concern only — never store "local" timestamps. Always store UTC, convert for display.
Integer overflow on 32-bit systems: see the Year 2038 problem below.
The Year 2038 Problem
32-bit signed integers can hold values up to 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. Systems that store Unix timestamps as 32-bit signed integers will overflow at that moment, causing dates to wrap to 1901 or crash. Modern systems use 64-bit integers, which won't overflow for approximately 292 billion years. If you're maintaining legacy systems, this is worth auditing.