getTimezoneOffset keeps or drops the seconds of local mean time as the claimed Chrome major does
A V8 browser claiming Chrome 156 or later returns a fractional getTimezoneOffset for a local-mean-time date; one claiming 155 or earlier returns whole minutes. N/A for zones without seconds in their mean time and for other engines (severity: info).
What a detector infers
Before the 1880s most places kept local mean time, and tzdb records those offsets to the second: New York's is −4:56:02. getTimezoneOffset is specified in minutes but may return a fraction, and V8 changed its answer between releases.
Measured on 2026-10-28 on Linux under America/New_York: Google Chrome 154.0.8037.57 and 155.0.8059.84 and Chromium 153 return 296 for 1 December 1060, while Google Chrome 156.0.8078.73 returns 296.0333… — the seconds kept — and Intl names −04:56:02 on all of them. A Clearcote r52 build on Chromium 156 returns 296.0333 too, on Linux and on a Windows host.
So an engine older than 156 that presents a Chrome 156 user agent reports whole minutes, and an engine from 156 on that claims an older major reports the fraction. Information only: genuine Google Chrome was measured on Linux only, and a zone whose mean time has no seconds (or UTC) cannot show it, which reads N/A.
How to resolve it
Claim the Chrome version the engine is. Nothing about this value can be changed from a script without breaking the Intl and parser agreement that timezone-history-date-vs-intl checks.
Nearby checks in Environment & locale
- Timezone is not UTC
timezone-not-utcThe check resolves the Intl zone and fails only when it is exactly 'UTC' or 'Etc/UTC'. - IANA zone offset matches the JS clock offset (incl. across DST)
timezone-offset-coherenceThis is a two-source cross-check on the same fact. It takes the resolved IANA zone, formats the current instant through Intl.DateTimeFormat… - Date and Intl give the same offset for dates decades and centuries back
timezone-history-date-vs-intlA browser answers 'what was the offset here on this date' from one copy of the time zone database, and three layers read it: Date's… - A three-digit year parses the way V8's date parser reads it
date-three-digit-year-vs-engineECMAScript only fixes how Date.parse reads its own ISO format; everything else is left to the engine, and engines differ at the edges. - navigator.plugins is consistent with the PDF viewer
has-pluginsAn empty navigator.plugins is only meaningful when it contradicts something else, and this check is written to respect that. - navigator.pdfViewerEnabled is true
pdf-viewerA direct read of navigator.pdfViewerEnabled. It is N/A when the property is not exposed at all, passes when true, and is marked false… - mimeTypes are consistent with navigator.plugins
plugins-mimetypesThis walks navigator.mimeTypes, and for each entry reads .enabledPlugin and checks that the exact object is present in a Set built from… - An enabled PDF viewer exposes exactly the specified plugin set
pdf-plugin-set-cardinalityA deployed commercial agent devotes four separate signals to this one small area: the plugin count, a plugin presence bit, the mime-type…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Environment & locale checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Environment & locale — the family timezone-offset-fractional-vs-major belongs to.