Developer tools · Unix timestamp converter
Leap seconds and Unix time: why the epoch pretends they do not exist
· Background
timestamps unix-time time-zones
UTC has inserted leap seconds since 1972, but Unix time simply does not count them, which means some seconds have happened twice. This post explains why, what smearing is, and why the whole practice is scheduled to end.
The second that happened twice — a 23:59:60 in one system, a repeated 23:59:59 in another, and a duplicate-key error at midnight
ToolAcre cannot produce an ISO row ending in `23:59:60`. Its test names the leap-second boundary and expects one epoch value to format as `2016-12-31T23:59:59.000Z` and the next as `2017-01-01T00:00:00.000Z`. There is no extra displayable second between them.
That fact can affect logs whose external source used another convention, but this repository contains no duplicate-key incident evidence. If repeated labels appear in a system, inspect that clock and storage path rather than attributing them automatically to the converter.
A system requiring a unique label for every physical second therefore needs more context than this Unix-to-Date mapping. The converter cannot manufacture a label its model omits.
ToolAcre proves no representable 23:59:60; it does not document duplicate-key incidents
The outline explained atomic time, Earth rotation and a tolerance threshold. Those scientific and standards claims are not established by the timestamp code or tests. They are intentionally left out rather than paraphrased from memory. Mechanism here does not prove the reasons behind global timekeeping policy.
For using this route, the evidence needed is simpler: Date and ISO output expose ordinary second labels, and the POSIX-style epoch advances across the tested boundary. A sourced treatment of leap-second governance would require authoritative material beyond the permitted repository paths.
This boundary is explicit rather than evasive: software tests answer representation questions, while scientific history needs material written for that purpose and reviewed on its own terms.
The physical rationale for leap seconds requires sources outside this repository
The implemented model behaves as though civil days on its axis have 86,400 numbered Unix seconds. Consecutive integer inputs differ by one second, including across the 2016 year boundary. `fromEpoch` multiplies each by 1,000 and Date formats the resulting millisecond count.
Calling this “ignoring” leap seconds describes observable output: no unique Unix value maps to a `:60` label. It does not imply every machine clock advances identically during a real insertion. The converter accepts a count; it does not sample or discipline the host clock.
Arithmetic across larger ranges follows the same convention, so subtracting two Unix values measures their POSIX-style count difference rather than reconstructing omitted leap labels.
The tested conversion has no leap-second label between consecutive epoch values
Systems can apply steps, repeats or smears, but the repository does not identify which providers use which method, over what interval or with what formula. Publishing those details without direct evidence would create operationally dangerous precision. This article therefore makes no platform-specific clock promise.
If events near a leap boundary matter, preserve the source’s clock documentation and raw values. Two systems with different handling can disagree even after both values are formatted as UTC. Conversion alone cannot reconcile their sampling behavior or recover an omitted scale distinction.
A runtime’s choice can also affect short-lived ordering around the event. Preserve monotonic counters or source-specific sequence data when that distinction matters operationally.
Clock-step and smear behavior is platform-specific and unverified here
Enter 1,483,228,799 seconds: the verified ISO result is `2016-12-31T23:59:59.000Z`. Increment the input once to 1,483,228,800: the result is `2017-01-01T00:00:00.000Z`. Subtracting the integers gives one, matching the displayed progression in this model.
The local rows may show different dates or offsets depending on the browser, but they derive from those same instants. Use the ISO rows for the boundary check. A local-zone change is unrelated to whether a leap-second label exists.
The pair is a useful regression test because there is no locale dependence in the ISO strings. It directly locks the converter’s behavior at the relevant edge.
Worked example: the repository’s tested 2016 boundary
The workbook referenced a 2022 resolution and a future deadline. No standards or policy source is part of the implementation evidence, so neither date nor forecast is asserted here. Timekeeping policy can change and deserves a current authoritative citation at publication time.
Omitting that claim does not weaken the software guidance. Existing data still needs its scale, unit and clock source documented. A converter’s current behavior remains testable independently of decisions about future civil-time practice.
Maintainers can add policy context later by citing the resolution directly. Until then, excluding a deadline is more accurate than publishing an unsupported future guarantee.
Future policy resolutions are omitted without an authoritative source
TAI, GPS and other scales can represent time differently, but ToolAcre offers no selector or offset table for them. Pasting such a count as Unix seconds merely applies the 1970 POSIX-style interpretation. A readable result can still be semantically wrong.
Transform other scales with a source that defines their origin and relationship at the relevant instant, then inspect the resulting Unix value. Do not add a remembered constant: relationships involving leap history are exactly where unsourced arithmetic becomes brittle.
The absence of a mode is visible in the UI’s three unit options. None changes time scale; automatic merely selects between two Unix resolutions.
Other time scales are outside this Unix converter’s implementation
For this converter, the verified rule is a direct step from 23:59:59 to 00:00:00 at the tested boundary. That model supports ordinary epoch arithmetic and explains why no `:60` output appears. It does not certify how an operating-system clock behaved while the real boundary passed.
When precision near leap handling matters, conversion is the last presentation step, not the evidence source. Collect clock-scale documentation, synchronization behavior and raw event fields first. ToolAcre can then show what a declared Unix count means under its tested model.
For ordinary logs away from leap boundaries, this nuance rarely changes display. Near sensitive boundaries, however, naming the model prevents false claims of physical-second fidelity.