Timestamp to Date Converter

What a Unix Timestamp Is

A Unix timestamp — also called epoch time or POSIX time — is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970. It is a single integer with no time zone, no locale, and no formatting, which is exactly why systems use it internally: two machines anywhere in the world will agree on what 1750000000 means, whereas they may well disagree about 03/04/2026.

The tradeoff is that a bare integer tells a human nothing. Converting between the two representations is a routine part of reading logs, debugging expiry bugs, and querying databases that store time as a number.

Seconds or Milliseconds?

The most common mistake by a wide margin. Unix time is defined in seconds, but JavaScript's Date.now(), Java's System.currentTimeMillis(), and most JavaScript-facing APIs use milliseconds — a value 1000x larger. Feed a millisecond value into a seconds-based parser and you land tens of thousands of years in the future; do the reverse and you get January 1970.

A quick heuristic for the current era: a 10-digit value is seconds, a 13-digit value is milliseconds. If a date comes back as 1970 or as some year in the 55th century, you have the units the wrong way round.

Where You Will Meet Epoch Values

• JWT claims. exp, iat, and nbf are all epoch seconds. If you are debugging a token specifically, the JWT Decoder converts them for you and flags an expired token outright.
• Server and application logs. Many structured loggers emit numeric timestamps so the value stays sortable and locale-independent.
• Database columns. Integer created_at columns are common in schemas that predate proper timestamp types, or that wanted to sidestep time zone handling.
• HTTP caching and rate limits. Headers such as X-RateLimit-Reset usually carry an epoch value telling you when your quota refills.
• Filesystem metadata. mtime, atime, and ctime are epoch seconds at the syscall level.
• Cron and scheduler state. Last-run and next-run bookkeeping is almost always stored as an integer.

UTC, Local Time, and Off-By-Hours Bugs

The epoch value itself is always UTC. The time zone only enters when you render it, which is where the confusion starts: your server logs in UTC, your browser displays local time, and your colleague three time zones away sees a third rendering of the same instant. When you and someone else disagree about when an event happened, compare the raw integers rather than the formatted strings — the integers cannot disagree.

Daylight saving transitions add a second trap. Local wall-clock time is not monotonic: an hour repeats in autumn and vanishes in spring, so "01:30 local" can be ambiguous or nonexistent. Storing and comparing epoch values sidesteps the problem entirely, which is the main argument for keeping UTC in the database and converting only at the display layer.

Boundaries Worth Knowing

• The 2038 problem. A signed 32-bit epoch overflows on 19 January 2038 and wraps to 1901. Modern systems use 64-bit time, but embedded devices, long-lived C code, and old database columns still carry the limit — and any system that computes a date far in the future can hit it well before 2038.
• Negative timestamps. Values before 1970 are legal and negative. Plenty of parsers handle them badly, which is a recurring source of bugs in date-of-birth fields.
• Leap seconds. Unix time deliberately ignores them, so it is not a true count of elapsed SI seconds. This matters for precision timing work and almost nowhere else.

Privacy

Conversion uses the browser's own Date and Intl APIs. Nothing you paste — including timestamps lifted straight out of production logs — is transmitted or stored.