Language, region, and time zone are independent settings

What it is

Independent language, region, and time-zone preferences model the language used by the interface, the regional conventions used for numbers and dates, and the civil time zone used for display as three separately valued and overridden fields. Language is commonly represented by a BCP 47 language tag that can include script and region subtags. Regional convention is not a national personality; it is explicit context required by formatting or business rules. Time zone uses an IANA time-zone identifier. A region subtag in a language tag still does not replace an independent time zone or the legal/service market assigned to an account.

Why it happens

The settings answer different questions. Language selects message catalogs, text direction, and linguistic resources. A formatting locale combines language, script, and regional conventions for dates, numbers, and week structure, while collation also needs an appropriate collation locale and tailoring. Time zone projects an instant into civil time. Someone can use one language, prefer another region's formats, and work in a third time zone without being an exceptional case. A robust model stores value, mode (automatic or explicit), provenance, and update time per field and resolves precedence independently. An explicit user choice normally supersedes account preference and device inference; a workspace policy overrides only fields it is entitled to manage; missing values use a documented product fallback. Service market, data residency, and legal entity remain separate authoritative attributes that an editable preference cannot override.

Studying it

Build an orthogonal language × region × time-zone matrix covering one language across regions, several languages in one region, travel, remote teams, shared devices, and system-setting changes. Assert message language, text direction, number/date/collation behavior, week start, and time labels separately to find components reading the wrong field. In user sessions, ask people to configure interface language, a formatting example, and current-city time, then complete scheduling and data-interpretation tasks; observe misselection, repeated changes, and understanding of labels. Reports need the provenance and precedence chain for every resolved value, or a wrong result cannot be traced to the layer that took control.

Where it stops holding

A locale is a structured set of linguistic and regional conventions, not a country and not an implicit time zone. One country may contain many languages and zones, while one language crosses regions. A region preference cannot establish where content may be sold, which law governs a person, or where data resides; those require independent business policy. Managed devices can fix particular display requirements without turning them into personal preference. Browser, operating system, account, and workspace signals may conflict and all automatic detection is uncertain, so the resolved value and source need to remain explainable.

Applying it

• Store ui_language, a complete format_locale (optionally with a separate region override), and IANA time_zone separately, each with auto/explicit/managed mode, provenance, version, and update time. Never persistently derive two from the third. If ordering is independently selectable, also store a collation_locale or tailoring rather than letting region alone decide it.
• Define precedence per field—for example explicit user choice, account value, device capability, then reviewed fallback—and state which fields organizational policy may manage. Keep legal entity, service market, and data residency as separate read-only business attributes.
• Confirm resolution through formatting and time previews, and summarize language, date/number examples, and zone together. Reuse the product's language-setting flow for entry and switching rather than creating another switcher inside the data model.
• Make formatters read format_locale, collation read the appropriate language/script/region and tailoring, notification scheduling read time_zone, and content loading read independent content-language preferences. Wrap or lint against implicit global-locale reads, test atypical combinations end to end, and log a non-sensitive provenance chain for diagnosis.

Related

• Same group: S4.02.2 Driving all three from one setting causes mismatches · S4.02.3 Interface language and content language can differ
• Adjacent: S4.01.1 Automatic language detection must be overrideable · S2.01.4 The first day of the week varies by region
• Search terms: locale preference model · BCP 47 language tag · IANA time zone