A release log contains 1767225600. A teammate pastes it into a date constructor and sees January 1970. The event was recorded in seconds, while the constructor expected milliseconds. The digits were correct; the contract was missing.
Run the same digits with two units
Open Timestamp Explorer. Choose UTC, enter the value below, and explicitly select Seconds.
Input: 1767225600
Unit: Seconds
Timezone: UTCThe expected outputs all describe one instant:
ISO 8601: 2026-01-01T00:00:00.000Z
Unix seconds: 1767225600
Unix milliseconds: 1767225600000Keep the same input and change the unit to Milliseconds. The expected ISO output becomes:
1970-01-21T10:53:45.600ZBoth results are valid dates. A plausible result cannot tell you which unit the producer intended. Digit counting is a heuristic, not a schema.
Normalize once, then derive every output
Diggwigs uses milliseconds from the Unix epoch as its base value. It derives the displayed date, ISO string, seconds, and milliseconds together. Seconds accept up to three fractional digits; milliseconds must be integers. A value outside the supported date range produces an error instead of a partial result.
Input: -0.001 seconds
Expected milliseconds: -1
Expected ISO: 1969-12-31T23:59:59.999ZTimezone changes the label, not the instant
Choose Local device timezone to see your system’s representation. The ISO output remains UTC and the epoch value remains unchanged. A calendar date is different: it must first be interpreted in the selected timezone to become an instant.
A daylight-saving transition can skip or repeat a local time. Nonexistent local times are rejected. For a repeated time, the browser chooses the earlier occurrence. Use UTC or an explicit offset in your data exchange when this distinction matters.
Put the unit in the field name, schema, or API contract.
created_at_msis more useful than a promise to guess later.