Developer tools · Unix timestamp converter
How the browser converts an epoch to local time with Date and Intl
· How it works
timestamps javascript browser-apis
A browser converter has no server clock or time zone database of its own; it relies on the Date object and the Intl API backed by your operating system. This post explains that pipeline and its limits.
Where does the browser get 'local' from? — the same epoch shown differently on a laptop and a phone in the same room
Two devices beside each other can render one epoch differently when their configured local zones differ. The integer does not change between the laptop and phone; each browser constructs the same instant, then supplies local calendar fields for its own environment. “Local” therefore describes the reader, not a property carried inside the epoch.
ToolAcre makes that dependency visible by labelling the local row with `Intl.DateTimeFormat().resolvedOptions().timeZone`. A screenshot that says one clock time and a server log that says another may both be faithful readings. Compare their UTC rows first; matching UTC output shows that presentation, rather than the underlying instant, differs.
Date takes milliseconds — the constructor's contract, why seconds must be multiplied by a thousand, and the range Date can represent
JavaScript `Date` receives milliseconds from the epoch. ToolAcre’s `fromEpoch` multiplies a seconds input by 1,000 and leaves a milliseconds input unchanged before constructing the object. That conversion is explicit because passing 1,717,243,200 directly to `new Date` would mean about twenty days after 1970, not June 2024.
The implementation rejects a non-finite number and any interpreted value beyond ±8.64×10¹⁵ milliseconds before formatting. That limit comes from the Date range named in the source, not from a database or operating-system clock. Changing the selector can move a value across the boundary, so an error also tells you which unit was applied.
UTC accessors versus local accessors — getUTCHours and getHours, and how the engine applies the offset
ToolAcre does not extract fields with `getUTCHours` and `getHours`; the outline’s accessor wording is more specific than the implementation. It asks `Intl.DateTimeFormat` to format the Date once with `timeZone: "UTC"` and once without a zone override. Both calls receive the same millisecond value, so neither can move the event itself.
That distinction matters when debugging. If the seconds and milliseconds rows agree with the producer but the local label surprises you, inspect the browser zone rather than adding hours to the epoch. Manual offset arithmetic would create a different instant and then let the formatter apply local rules again, producing the classic double-adjustment error.
UTC and local formatting ask the engine for two readings of one Date
The converter can prove that it asks the browser for `resolvedOptions().timeZone`; it cannot prove whether a particular engine obtained every time-zone rule from the operating system, bundled data or another platform layer. The source deliberately treats that machinery as an engine responsibility and falls back to the phrase “local time” if the zone query fails.
This evidence boundary is useful. A named zone in the result identifies the browser’s current choice, but it is not a version report for a time-zone database. If two environments disagree on an old date, record browser, operating system and displayed zone. The converter supplies the observation; it does not diagnose the data package behind Intl.
The browser reports a local zone, while its rule source remains an implementation detail
For the ISO row, `toISOString()` supplies a UTC string with a trailing Z and three fractional digits. Human-readable UTC and local rows use an English Great Britain formatter with numeric year, abbreviated month, two-digit day and a 24-hour clock. The formatter also requests `shortOffset`, making the applicable offset part of each rendered row.
Those choices explain why copying `Date.toString()` from a console is not equivalent evidence. Its exact prose is locale-dependent and outside this tool’s output contract. ToolAcre fixes its display options, while still allowing the actual local zone to vary. Copy the ISO value when another system needs a stable machine-readable comparison.
Worked example: one epoch, three outputs — a UTC ISO string, a locally formatted time and the offset in minutes from getTimezoneOffset
Enter 1,717,243,200 and choose seconds. Multiplication produces 1,717,243,200,000 milliseconds, which the tests establish as `2024-06-01T12:00:00.000Z`. The UTC row formats that instant in UTC; the local row formats the identical Date in the browser zone and names that zone. The seconds and milliseconds rows preserve both numerical forms.
The precise local clock and offset must be read from the device running the example; publishing one here would pretend every reader has the same zone. That is why this worked check uses the ISO assertion as its fixed result and treats local output as an observed value. If ISO differs, revisit the selected unit before investigating location settings.
Worked example: one epoch, the three outputs ToolAcre actually exposes
This route does not offer a selector for an arbitrary third zone. `formatInZone` can accept a zone internally, but the panel calls it for UTC and for the browser default only. An article claiming that users can choose Tokyo, Nairobi or Toronto would describe an interface that is not shipped, even though Intl can support such formatting elsewhere.
It also does not expose calendar selection, locale selection or a time-zone database revision. For cross-office conversion, retain the epoch as the anchor and use a tool whose documented interface names the target zone. Here the narrower promise is valuable: universal UTC beside the local environment, with no hidden server deciding what local means.
Takeaway: your browser is the clock and the atlas — and how the Unix timestamp converter uses it to show UTC and local side by side without a server
The browser acts as both arithmetic engine and presentation environment. ToolAcre resolves the unit, creates one Date, asks for a canonical ISO value, then formats UTC and local readings side by side. No remote conversion service is needed for those steps, and the displayed unit keeps the factor-of-1,000 decision available for review.
When outputs disagree across devices, compare the ISO row, the unit note and the named local zone in that order. Those three observations separate instant, scale and presentation. Treating the local clock as the source of truth collapses all three questions into one and makes a correct conversion look wrong whenever the viewer changes zones.