Date and Intl give the same offset for dates decades and centuries back
For each year, getTimezoneOffset and Intl's longOffset name the same offset within a minute; on V8 the local and UTC parses differ by that same offset. N/A without longOffset support (severity: warn).
What a detector infers
A 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 getTimezoneOffset, Intl's longOffset time zone name, and the date parser, which reads '12/1/1937' as local time and '1937-12-01' as UTC. Spoofing tools usually move only today's offset — a getTimezoneOffset that returns a constant, or an Intl.DateTimeFormat whose resolvedOptions names a new zone — and tzdb's history then gives them away.
New York's offset in 1060 is its local mean time, 4 hours 56 minutes and 2 seconds west; Amsterdam's in 1945 was an hour east while its 1937 midnight fell at UTC. The row asks for local midnight on 1 December of 1060, 1900, 1937, 1945 and 1989 through all three layers and requires them to agree within a minute (V8 before Chrome 156 rounds the local-mean-time seconds away).
A widely deployed CAPTCHA's challenge script reads the same kind of dates (999, 1060, 1937, 1945 and 1989). Measured on 2026-10-28 on Linux with Google Chrome 154, 155 and 156, Chromium 153 and a Clearcote r52 build under America/New_York and Europe/Amsterdam: every layer agreed in every year. N/A where Intl cannot produce a longOffset name.
How to resolve it
Set the time zone below JavaScript — the TZ environment variable, the operating system, or a browser that switches its own time zone — so every layer reads the same tzdb entry. A script patch of getTimezoneOffset or Intl changes the present and leaves the past pointing at the real zone.
Nearby checks in Environment & locale
- The field-trial state of this build is reported (XSLT warning banner)
xslt-banner-readoutChrome is deprecating XSLT, and a fresh Chrome 155 profile shows it: an XML document styled with XSLT is rendered with a red deprecation… - Intl timezone resolves
timezone-presentThis check reads Intl.DateTimeFormat().resolvedOptions().timeZone and records it alongside -new Date().getTimezoneOffset() and… - 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… - 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. - getTimezoneOffset keeps or drops the seconds of local mean time as the claimed Chrome major does
timezone-offset-fractional-vs-majorBefore the 1880s most places kept local mean time, and tzdb records those offsets to the second: New York's is −4:56:02. getTimezoneOffset… - 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…
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-history-date-vs-intl belongs to.
