Unix Timestamps in Seconds, Milliseconds, and Microseconds
Distinguish Unix timestamp seconds, milliseconds, and microseconds, recognize common digit lengths, and avoid 1,000-times unit errors.
Is this Unix timestamp in seconds, milliseconds, or microseconds?
Short answer: for dates near the present, a Unix timestamp with about 10 digits is usually seconds, 13 digits is usually milliseconds, and 16 digits is usually microseconds. The unit is not encoded in the number, however. Digit length is a useful clue, not proof. When the producer's documentation is available, use its declared unit.
All three values can name the same instant. They differ only in scale: one second contains 1,000 milliseconds and 1,000,000 microseconds. Treating a millisecond value as seconds moves it far outside an ordinary date range; treating a seconds value as milliseconds puts it near January 1970.
One instant written in three units
| Unit | Example | Scale to milliseconds |
|---|---|---|
| Seconds | 1700000000 | Multiply by 1,000 |
| Milliseconds | 1700000000000 | Use directly |
| Microseconds | 1700000000000000 | Divide by 1,000 |
These three examples all convert to 2023-11-14T22:13:20.000Z. The trailing zeros in the finer units do not add information here. A real microsecond source could use nonzero final digits, but a browserDate cannot retain precision finer than one millisecond.
What the Unix epoch means
The reference instant is 1970-01-01 00:00:00 UTC. Positive values are after that instant; negative values are before it. Unix-style time representations ordinarily exclude leap seconds, so they should not be read as a count of every physical SI second inserted into civil timekeeping.
A timestamp identifies an instant. It does not contain a city, local timezone, daylight-saving label, or human display format. Formatting the same instant in New York, London, Tokyo, or UTC changes the visible clock and date, not the underlying timestamp.
How iLoveTimers detects the unit
The production Unix timestamp converter offers explicit Seconds, Milliseconds, and Microseconds modes. Its Auto mode removes a leading sign plus commas or underscores for the digit check, then applies these implementation thresholds:
- 15 or more integer digits: interpret as microseconds.
- 12 to 14 integer digits: interpret as milliseconds.
- Fewer than 12 integer digits: interpret as seconds.
The thresholds make common modern timestamps convenient, but they are deliberately described as inference. A far-future seconds value, an old short millisecond value, or an application-specific counter can be misclassified. Select the unit manually when you know it.
How conversion and truncation work
The converter normalizes the chosen input to milliseconds because the browser's Date representation uses milliseconds. Seconds are multiplied by 1,000. Microseconds are divided by 1,000. Sub-millisecond remainder is truncated, and the interface reports that truncation. The result is rejected if it is not numeric or falls outside the browser Date range protected by the implementation.
For example, 1700000000000123 microseconds normalizes to 1700000000000.123 milliseconds. The Date result retains 1700000000000 milliseconds. The final 123 microseconds cannot be shown by that Date object. This is a representation limit, not evidence that the original source never measured those digits.
The reverse form accepts a date and clock input explicitly as UTC, validates its calendar fields, and returns both seconds and milliseconds. That UTC label matters. Interpreting the same wall-clock fields as local time would name a different instant in most timezones.
Common failure patterns
- A 1970 result: a seconds value was probably treated as milliseconds.
- An out-of-range result: a millisecond or microsecond value may have been treated as seconds.
- A time off by several hours: the unit may be right, but UTC and local wall time were confused.
- Lost final digits: microseconds were normalized to a millisecond Date representation.
- A plausible but wrong date: Auto mode inferred a unit from digit length that did not match the producing system.
Preserve the original value while you investigate. Converting it in place and saving only the guessed result can erase the clue that would have revealed the unit. When an API or database schema names the unit, record that declaration beside the field instead of relying on its present digit length. Values grow over time, so a threshold that looks obvious today is not a permanent data contract.
Current timestamps still depend on the device clock
The live Unix time clock reads the browser's current Date value and shows seconds and milliseconds. It does not query an external time authority. If the device clock is wrong, both displayed units inherit that error. Extra displayed digits describe the unit and update cadence, not independent synchronization accuracy.
Sources and further reading
These external references support the browser and standards behavior described above. iLoveTimers implementation details are identified separately in the guide.
- W3C High Resolution Time: defines an epoch timestamp representation as integral milliseconds from the Unix epoch and excludes leap seconds
- ECMAScript specification: Date objects: defines ECMAScript time values and the Date range and millisecond representation used by browser Date objects
- MDN: Date.getTime(): documents that JavaScript Date returns milliseconds since the Unix epoch
Related iLoveTimers guides
- Daylight-Saving Gaps, Repeated Times, and Timezone Conversions
- How Browser Timers Measure Elapsed Time and Handle Delays
Read how these explanations are checked on How iLoveTimers Is Made, or report a problem through the contact page.