intl_locale: Intl locale, calendar and hour cycle signal

intl_locale at a glance (from the library code, signalsVersion 5)
Component name	`intl_locale`
In the visitorId	yes
structuredId group	locale
Hashing	plain value; a digest only when longer than 128 characters or not printable ASCII
Excluded under	no browser class
Inner timeout	1000 ms
Added in	signalsVersion 2

In plain words

Browsers format dates and numbers the local way: which calendar, which digits, a 12 or a 24 hour clock. WhiskerJS asks the browser’s formatting engine which settings it would use and writes them down. They follow the language and region settings of the device and rarely change.

What it reads

from new Intl.DateTimeFormat().resolvedOptions(): locale, calendar and numberingSystem;
from new Intl.DateTimeFormat(undefined, { hour: 'numeric' }).resolvedOptions(): hourCycle;
from new Intl.NumberFormat().resolvedOptions(): locale.

The value is locale=…;calendar=…;numbering=…;hour_cycle=…;number_locale=…. A failed hour cycle or number format read is written as ! inside the value. If no date locale is resolved, the component is unavailable / no_value.

How the technique works

The Intl API resolves the requested default locale against the data the engine ships and the operating system’s regional settings. The result shows not only the language but also derived formats: a Gregorian or another calendar, Latin or other digits, and the hour cycle. The hour cycle is read with an explicit hour option because only then does the engine resolve it.

Why it helps

Two users with the same language list can still differ here, for example by region or by a 24 hour clock setting. It is part of the locale group of the structuredId.

Stability

It changes when the user changes language or region settings, or when a browser update ships different locale data (rare). Travel does not change it unless the device’s region settings change.

Browser support and what blocks it

ok in all current browsers; not in the exclusion table. unavailable / no_api only where Intl.DateTimeFormat is missing. Some privacy modes normalise the locale (for example to en-US); WhiskerJS reports what the browser resolves.

Privacy

Regional formatting preferences, read without permission or prompt, never sent by WhiskerJS. The value is short ASCII and reported as plain text.

How WhiskerJS handles noise and failures

Status	ruleId	When
`ok`	none	the five fields
`unavailable`	`no_api`	no `Intl.DateTimeFormat`
`unavailable`	`no_value`	no resolved locale
`blocked`	`security_error`, `threw`	the main `resolvedOptions` call threw
`excluded`	`caller_excluded`	your `exclude` list
`timed_out`	`timeout`, `aborted`	1000 ms inner timeout, budget, abort

Example value

From the headless test browsers in a container (all three agreed):

"intl_locale": {
  "status": "ok",
  "value": "locale=en-US;calendar=gregory;numbering=latn;hour_cycle=h12;number_locale=en-US",
  "hashed": false
}

Questions and answers

How is intl_locale different from languages?

languages is the user's list of preferred languages. intl_locale is what the JavaScript Intl API actually resolves to for dates and numbers, including the calendar, digits and 12 or 24 hour clock, which also follow regional settings.

What does hour_cycle h12 or h23 mean?

It is the clock format Intl uses for hours: h12 is a 12 hour clock with AM and PM, h23 a 24 hour clock from 0 to 23. It follows the locale and, in some systems, the user's clock setting.

languagesThe language list.time_zoneThe IANA time zone.Signal groupintl_locale is in the locale group.Comparing two resultsWhat a change in the locale part means.

intl_locale