Timestamp Units: Seconds vs Milliseconds vs Microseconds

A timestamp unit tells you how finely time is counted. Unix timestamps often use seconds, JavaScript commonly uses milliseconds, databases may store microseconds, and high-resolution systems can reach nanoseconds. The numbers can look similar until a unit mistake produces a date thousands of years away.

The Unit Ladder

• 1 second = 1,000 milliseconds
• 1 millisecond = 1,000 microseconds
• 1 microsecond = 1,000 nanoseconds
• 1 second = 1,000,000 microseconds
• 1 second = 1,000,000,000 nanoseconds

Each step adds three decimal digits of precision. Converting to a finer unit multiplies. Converting to a coarser unit divides and may discard a remainder.

Recognizing a Modern Unix Timestamp

Near the 2020s, a Unix value in seconds has about 10 digits. The same instant has about 13 digits in milliseconds, 16 in microseconds, and 19 in nanoseconds.

For example, the instant represented by 1700000000 seconds can also be written as:

• 1700000000000 milliseconds
• 1700000000000000 microseconds
• 1700000000000000000 nanoseconds

Digit length is a quick clue, not a formal guarantee. Values from much earlier or later dates have different lengths, and some systems use a non-Unix epoch.

Fractional Seconds Preserve Precision

RFC 3339 timestamps can express subsecond precision after a decimal point, such as 2026-07-18T12:34:56.123456Z. Six digits after the decimal represent microseconds here. The value is still a date-time string, while a raw integer may store the same precision as a count from an epoch.

Conversion and Rounding

Suppose an API returns 1700000000123456 microseconds. Dividing by 1,000 gives 1700000000123.456 milliseconds. An integer-millisecond system must choose what to do with the .456 remainder. Truncating, rounding, and retaining a separate remainder are different behaviors.

For event ordering, truncating several values into the same millisecond may erase their original sequence. Preserve the highest available precision until the final display or export step.

Storage Range Matters Too

Finer units consume the numeric range faster. A signed 64-bit counter in nanoseconds reaches its limit far sooner than a signed 64-bit counter in seconds. Choosing a unit is therefore a trade between precision and representable date range.

Floating-point numbers introduce another issue. As their magnitude grows, they cannot represent every adjacent integer. JavaScript numbers can exactly hold many current millisecond timestamps but are unsuitable for arbitrary nanosecond integers without BigInt or another representation.

Preventing Unit Bugs

Name variables with the unit, such as createdAtMs or timeoutSeconds. Document the epoch and whether values may be fractional. Validate plausible ranges at API boundaries. A current seconds timestamp interpreted as milliseconds lands near January 1970, while a current millisecond value interpreted as seconds produces an impossible far-future date. Rejecting those results early is safer than guessing silently.

Precision Is Not Accuracy

A sensor can return six fractional digits even if its clock is wrong by a second. Precision describes the size of the represented step; accuracy describes closeness to the intended time. Resolution is the smallest change the system can observe. Those properties should not be inferred from digit count alone.

Database columns can create a similar illusion. A microsecond column may pad a millisecond input with three zeros. The stored value looks more precise without containing more information.

Negative Values and Different Epochs

Signed Unix timestamps can represent instants before 1970 with negative numbers. Not every API accepts them, and unsigned storage cannot express them. Windows file time, spreadsheet serial dates, GPS time, and NTP use other reference points or rules. A large integer is not automatically Unix time.

At every integration boundary, document four items: epoch, unit, signed range, and treatment of leap seconds. A short schema note prevents more errors than a clever digit-length detector.

An API Test Set

Test an epoch value, a current value, a value with a nonzero fractional remainder, a negative value if supported, and the largest accepted value. Round-trip each one from number to date and back. This catches unit truncation and overflow before production data becomes irreversible.