Unix Timestamp Units: Seconds to Nanoseconds

Four units, one shared epoch

Unix timestamps commonly use seconds, but many APIs and databases express the same elapsed time in smaller units. A millisecond is one thousandth of a second; a microsecond is one millionth; a nanosecond is one billionth. Changing the unit changes the number, not the represented instant. The epoch remains January 1, 1970 at 00:00:00 UTC.

Digit counts are a clue, not a contract

The 10/13/16/19 pattern is useful for contemporary timestamps. It is not a universal identification rule: values near 1970 have fewer digits, and distant future dates may have more. For example, 1000 milliseconds means one second after the epoch; 1000 seconds means sixteen minutes and forty seconds after it.

Prefer the API documentation, database column definition, or original producer’s specification over an inferred unit. The converter’s Auto-detect option uses digit count as a convenience. Select a unit explicitly when you know it, particularly for historical data, small values, and timestamps supplied as decimals.

A worked example with nine fractional digits

The nanosecond timestamp 1767225600123456789 corresponds to 2026-01-01T00:00:00.123456789Z. Dividing by the appropriate power of 1,000 gives the equivalent values below. The decimal point moves, while the instant remains identical.

Preserve large integers before converting them

JavaScript Number values cannot represent every integer beyond 9,007,199,254,740,991 exactly. A contemporary nanosecond timestamp exceeds that boundary. Keep it as a decimal string or BigInt while performing integer arithmetic; converting an already rounded Number to BigInt cannot recover the original digits.

A JavaScript Date stores whole milliseconds, with a supported range of ±100 million days from the epoch. It cannot store all nine fractional digits itself. This converter keeps the nanosecond integer separately, uses Date for calendar fields, and preserves the full fraction in the ISO result. Integer outputs in coarser units intentionally drop the remaining fraction.

const nanoseconds = BigInt("1767225600123456789");
const wholeMilliseconds = nanoseconds / 1000000n;
const date = new Date(Number(wholeMilliseconds));
// Date retains .123 seconds; the original BigInt retains .123456789.

Check rounding rules for dates before 1970

This converter floors integer unit conversions toward negative infinity. Consequently, minus one nanosecond becomes minus one whole millisecond or minus one whole second when expressed in those coarser integer units. The exact instant is still 1969-12-31T23:59:59.999999999Z. JavaScript BigInt division instead truncates toward zero, so the simple division example above needs a floor adjustment for negative values with a remainder.

More digits do not create a more accurate clock

Date.now() returns whole milliseconds, and browsers may reduce its precision further. Multiplying that reading by one million expresses it in nanoseconds without measuring any additional detail. The live epoch clock here therefore has millisecond source precision, even when a finer unit is displayed. Use a timestamp supplied by an appropriately precise source when sub-millisecond detail matters.