Unix Timestamp FAQ

FAQ

What is a Unix timestamp?

A Unix timestamp is the number of seconds that have elapsed since the Unix epoch — January 1, 1970 at 00:00:00 UTC. It is a language-neutral, timezone-independent integer that uniquely identifies any moment in time.

What is the Unix epoch?

The Unix epoch is January 1, 1970 at 00:00:00 UTC. All Unix timestamps are measured forward — or backward for negative values — from this fixed reference point. The choice of 1970 was practical: it was a recent, round year when Unix was being designed at Bell Labs.

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

A 10-digit timestamp (e.g. 1700000000) represents seconds since the epoch. A 13-digit timestamp (e.g. 1700000000000) represents milliseconds. JavaScript's Date.now() returns milliseconds; most Unix system calls and languages like Python, Go, and PHP return seconds by default.

Why does JavaScript use milliseconds instead of seconds?

JavaScript's Date API was designed to match the resolution of system timers available in 1995. Using milliseconds avoids precision loss for sub-second durations. When working with server-generated Unix timestamps in seconds, multiply by 1000 before passing to new Date().

How do I convert a Unix timestamp to a readable date in JavaScript?

For a seconds timestamp: new Date(1700000000 * 1000).toISOString(). For a milliseconds timestamp: new Date(1700000000000).toISOString(). Both produce ISO 8601 strings like '2023-11-15T06:13:20.000Z'. Use toLocaleString() with a timeZone option for localized display.

Are Unix timestamps timezone-aware?

No. A Unix timestamp always represents a single moment in UTC. Timezone information is only applied when formatting the timestamp for display. Two devices in different timezones will produce the same Unix timestamp for the same instant.

What is the Year 2038 problem?

Systems that store Unix timestamps as 32-bit signed integers can only represent values up to 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC. After that moment the integer overflows to a large negative number. Modern 64-bit systems are not affected, but embedded systems and legacy databases may still be at risk.

What is a negative Unix timestamp?

A negative Unix timestamp represents a moment before the Unix epoch. For example, -86400 is December 31, 1969 at 00:00:00 UTC. Most modern date APIs handle negative timestamps correctly, but some older systems and databases do not support them.

How do I get a Unix timestamp in Python?

Use import time; int(time.time()) for seconds. For an explicit UTC datetime: import datetime; int(datetime.datetime.now(datetime.timezone.utc).timestamp()). For milliseconds: int(time.time() * 1000).

How precise is a Unix timestamp?

A standard Unix timestamp has one-second precision. For sub-second precision, millisecond timestamps (13 digits) are common in web APIs and JavaScript. Some systems use microseconds (16 digits) or nanoseconds. The appropriate unit depends on the precision your application actually needs.

How big can a Unix timestamp be?

On a 64-bit signed integer (today’s standard), Unix timestamps can represent any moment from roughly 292 billion years ago to 292 billion years in the future. The famous 32-bit limit (the Year 2038 problem) only applies to legacy systems.

Why does my timestamp show 1970?

Usually one of three reasons: the value is 0 (the epoch itself), the value is in milliseconds but was treated as seconds (so it rounds to a tiny seconds value near 0), or the value is null/undefined and your code defaulted it to 0.

What is the difference between UTC and GMT?

For most purposes UTC and GMT are interchangeable. UTC (Coordinated Universal Time) is the modern atomic standard; GMT (Greenwich Mean Time) is a legacy term for the timezone at zero offset. The UK and most software treat them as equivalent.

Should I store dates as Unix timestamps or as ISO 8601 strings?

Both work. Unix integers are compact and trivial to compare; ISO 8601 strings are self-describing and human-readable. In databases, native datetime types (TIMESTAMP WITH TIME ZONE in Postgres, DATETIME(6) in MySQL) are usually best because they preserve timezone semantics and index efficiently.

Is my server’s local time safe to store?

No. Storing local time without an offset loses information whenever the server moves, DST changes, or another server in a different zone reads the value. Store UTC (as a Unix timestamp or a timezone-aware datetime) and only convert to local time at the display layer.

Do Unix timestamps include leap seconds?

POSIX Unix time deliberately ignores leap seconds — every Unix day is exactly 86,400 seconds even when an extra UTC second is inserted. The actual second number is repeated or the clock is smeared, depending on the system.