Timezone, Locale, and Language Fingerprinting Guide

Regional settings as one unit

Your browser exposes geographic information through multiple channels: timezone via the Intl API, locale through number and date formatting, language via navigator.language and the Accept-Language header, and geolocation through the Geolocation API. These four properties form the geographic layer of your browser identity. When they do not align with each other or with your IP address, the inconsistency is visible.

BotBrowser provides dedicated CLI flags to configure each regional property. By default, settings left on auto derive from the selected proxy route. This article covers automatic values, explicit overrides, and configuration strategies for multi-region workflows.

Privacy Impact

Geographic metadata is one of the most commonly checked aspects of browser identity. Tracking systems compare:

• IP geolocation vs. timezone: An IP address in Germany with a timezone of America/New_York is an obvious mismatch
• Locale vs. language: A de-DE locale with Accept-Language: en-US alone is unusual
• Language vs. IP region: A Japanese IP with only English language preferences may indicate misconfiguration
• Geolocation coordinates vs. IP: If the Geolocation API returns coordinates in Tokyo but the IP resolves to New York, the conflict is clear

These checks are simple and fast, making them an early filter in any tracking pipeline. Getting geographic consistency right is a necessary foundation for any privacy-focused browsing setup.

BotBrowser's automatic geographic detection eliminates the most common source of these mismatches: manual configuration errors. When you connect through a proxy, BotBrowser detects the proxy's IP and derives timezone, locale, language, and geolocation automatically.

How regional values relate

How Browsers Expose Geographic Information

Timezone: JavaScript's Intl.DateTimeFormat().resolvedOptions().timeZone returns the IANA timezone name (e.g., America/New_York). The Date object's getTimezoneOffset() method returns the UTC offset in minutes. Both must be consistent with each other and with the claimed location.

Locale: The Intl.NumberFormat().resolvedOptions().locale and Intl.DateTimeFormat().resolvedOptions().locale reveal the browser's formatting locale. This affects number formatting (comma vs. period for decimals), date formatting (DD/MM vs. MM/DD), and currency formatting.

Language: navigator.language returns the primary language, and navigator.languages returns the full list of preferred languages. The Accept-Language HTTP header sends these preferences with every request.

Geolocation: The navigator.geolocation.getCurrentPosition() API returns GPS-like coordinates. This requires user permission, but when granted, the coordinates must be plausible given the IP and timezone.

The Consistency Chain

These signals form a chain that must be internally consistent:

IP address → Country → Timezone → Locale → Languages → Geolocation

Each step must logically follow from the previous one. A proxy IP in Japan should produce:

• Timezone: Asia/Tokyo
• Locale: ja-JP
• Languages: ja-JP,ja,en
• Geolocation: coordinates in Japan (if queried)

Breaking any link in this chain creates a detectable inconsistency.

DST and UTC Offsets

Timezone configuration must account for Daylight Saving Time (DST). Using UTC offsets like UTC-5 instead of IANA timezone names like America/New_York fails when DST transitions occur. America/New_York is UTC-5 in winter and UTC-4 in summer. A fixed UTC offset does not handle this transition, creating a seasonal mismatch that reveals the timezone was manually configured.

BotBrowser uses IANA timezone names internally, ensuring correct DST behavior throughout the year.

Where configuration can drift

Framework-Level Timezone and Locale

Playwright provides timezoneId and locale options per context:

const context = await browser.newContext({
  timezoneId: 'America/New_York',
  locale: 'en-US',
});

This changes Intl API behavior and navigator.language, but:

• Geolocation coordinates are not affected
• The Accept-Language header may not fully align
• The timezone offset in Date.getTimezoneOffset() may not update consistently in all contexts

Manual Header Setting

Setting Accept-Language via page.setExtraHTTPHeaders() changes the HTTP header but not navigator.language or navigator.languages. The mismatch between HTTP and JavaScript values is detectable.

VPN with System Timezone

Changing your system timezone to match a VPN works but affects all applications, not just the browser. It also requires administrative access and manual intervention for each region change.

BotBrowser's Approach

Automatic Geographic Detection

By default, BotBrowser auto-derives all geographic settings from the proxy IP:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@jp-proxy:1080

BotBrowser detects the Japanese IP and automatically configures:

• Timezone: Asia/Tokyo
• Locale: ja-JP
• Languages: ja-JP,ja,en
• Geolocation: coordinates approximated from the IP

No additional flags are needed. The auto behavior is the default for all geographic settings.

Manual Override Flags

When you need specific geographic settings, four CLI flags provide complete control:

--bot-config-timezone (ENT Tier1): Set the IANA timezone.

--bot-config-timezone=America/New_York    # Specific timezone
--bot-config-timezone=auto                # Derive from IP (default)
--bot-config-timezone=real                # Use system timezone

--bot-config-locale (ENT Tier1): Set the browser locale.

--bot-config-locale=en-US    # Specific locale
--bot-config-locale=auto     # Derive from IP/language (default)

--bot-config-languages (ENT Tier1): Set language preferences.

--bot-config-languages=en-US,en          # Specific languages
--bot-config-languages=auto              # Derive from IP (default)

--bot-config-location (ENT Tier1): Set geolocation coordinates.

--bot-config-location=40.7128,-74.0060   # Specific coordinates
--bot-config-location=auto               # Derive from IP (default)
--bot-config-location=real               # Use system GPS

Consistent browser configuration

BotBrowser applies these values as browser configuration, which means:

• Timezone: Intl.DateTimeFormat().resolvedOptions().timeZone and Date.getTimezoneOffset() both reflect the configured timezone, including correct DST behavior
• Locale: All Intl formatters (NumberFormat, DateTimeFormat, Collator) use the configured locale
• Languages: navigator.language, navigator.languages, and the Accept-Language HTTP header all align
• Geolocation: navigator.geolocation.getCurrentPosition() returns the configured coordinates

All values are consistent across the main thread, workers, and HTTP headers.

Setting regional values

Full Geographic Configuration (CLI)

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@us-east.proxy:1080 \
       --bot-config-timezone=America/New_York \
       --bot-config-locale=en-US \
       --bot-config-languages=en-US,en \
       --bot-config-location=40.7128,-74.0060

Common Region Configurations

Region	Timezone	Locale	Languages	Coordinates
US East	America/New_York	en-US	en-US,en	40.7128,-74.0060
US West	America/Los_Angeles	en-US	en-US,en	34.0522,-118.2437
UK	Europe/London	en-GB	en-GB,en	51.5074,-0.1278
Germany	Europe/Berlin	de-DE	de-DE,de,en	52.5200,13.4050
France	Europe/Paris	fr-FR	fr-FR,fr,en	48.8566,2.3522
Japan	Asia/Tokyo	ja-JP	ja-JP,ja,en	35.6762,139.6503
South Korea	Asia/Seoul	ko-KR	ko-KR,ko,en	37.5665,126.9780
Brazil	America/Sao_Paulo	pt-BR	pt-BR,pt,en	-23.5505,-46.6333
Australia	Australia/Sydney	en-AU	en-AU,en	-33.8688,151.2093

Playwright Integration

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=path/to/profile.enc',
      '--proxy-server=socks5://user:pass@us-east.proxy:1080',
      '--bot-config-timezone=America/New_York',
      '--bot-config-locale=en-US',
      '--bot-config-languages=en-US,en',
      '--bot-config-location=40.7128,-74.0060',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();

  const tz = await page.evaluate(() =>
    Intl.DateTimeFormat().resolvedOptions().timeZone
  );
  const langs = await page.evaluate(() => navigator.languages);
  const locale = await page.evaluate(() =>
    Intl.NumberFormat().resolvedOptions().locale
  );

  console.log('Timezone:', tz);     // America/New_York
  console.log('Languages:', langs); // ['en-US', 'en']
  console.log('Locale:', locale);   // en-US

  await browser.close();
})();

Multi-Region Setup

For workflows that span multiple regions:

const regions = [
  {
    profile: 'profiles/us-user.enc',
    proxy: 'socks5://user:pass@us.proxy:1080',
    timezone: 'America/New_York',
    locale: 'en-US',
    languages: 'en-US,en',
    location: '40.7128,-74.0060',
  },
  {
    profile: 'profiles/de-user.enc',
    proxy: 'socks5://user:pass@de.proxy:1080',
    timezone: 'Europe/Berlin',
    locale: 'de-DE',
    languages: 'de-DE,de,en',
    location: '52.5200,13.4050',
  },
  {
    profile: 'profiles/jp-user.enc',
    proxy: 'socks5://user:pass@jp.proxy:1080',
    timezone: 'Asia/Tokyo',
    locale: 'ja-JP',
    languages: 'ja-JP,ja,en',
    location: '35.6762,139.6503',
  },
];

for (const cfg of regions) {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      `--bot-profile=${cfg.profile}`,
      `--proxy-server=${cfg.proxy}`,
      `--bot-config-timezone=${cfg.timezone}`,
      `--bot-config-locale=${cfg.locale}`,
      `--bot-config-languages=${cfg.languages}`,
      `--bot-config-location=${cfg.location}`,
    ],
    headless: true,
  });

  // Run region-specific tasks...
  await browser.close();
}

Priority in the current release

BotBrowser now applies one clear priority order to timezone, locale, language, and location. A value supplied directly at launch has the highest priority. If launch configuration leaves a setting on auto, a value in the selected profile's configs section is used. If neither layer supplies an explicit value, the setting follows the selected proxy route.

The order is evaluated for each setting rather than for the group as a whole. A deployment can therefore pin a required language at launch, keep a profile-defined timezone, and allow location to follow the proxy. This flexibility is useful, but every explicit exception should have an owner and a documented reason.

The meaning of auto is important. It is not a value that replaces an explicit profile setting. It delegates the choice to the next applicable source. Removing an explicit launch value may reveal a profile value before proxy-derived selection becomes active.

Review configuration from top to bottom when a regional result is unexpected:

1. Check the effective launch values for the affected setting.
2. Check the selected profile's configs value for the same setting.
3. Confirm the proxy route assigned to that context.
4. Create a fresh context after changing any of these inputs.
5. Validate the application outcome in that context.

Keep launch templates, profile revisions, and proxy assignments in one release record. This makes rollback practical because the team can restore a known combination instead of changing several regional inputs independently.

For staged rollout, choose representative profile and proxy combinations. Confirm date and number presentation, content language, and application location behavior through normal product workflows. Review contexts separately, especially when one worker hosts several regional assignments.

Avoid copying explicit values into every template merely to make the configuration look complete. An unnecessary override becomes stale when a profile or route changes. Prefer auto when the proxy should own the regional choice, and use an explicit value only when the application has a stable requirement.

Checking regional alignment

After configuring geographic settings, verify all properties:

const page = await context.newPage();

// Timezone
const tz = await page.evaluate(() =>
  Intl.DateTimeFormat().resolvedOptions().timeZone
);

// Timezone offset (should be correct for current date/DST)
const offset = await page.evaluate(() => new Date().getTimezoneOffset());

// Locale from number formatting
const locale = await page.evaluate(() =>
  Intl.NumberFormat().resolvedOptions().locale
);

// Languages
const lang = await page.evaluate(() => navigator.language);
const langs = await page.evaluate(() => navigator.languages);

// Date formatting (locale-specific)
const dateFormat = await page.evaluate(() =>
  new Date().toLocaleDateString()
);

// Number formatting (locale-specific)
const numFormat = await page.evaluate(() =>
  (1234567.89).toLocaleString()
);

console.log('Timezone:', tz);
console.log('Offset:', offset);
console.log('Locale:', locale);
console.log('Language:', lang);
console.log('Languages:', langs);
console.log('Date format:', dateFormat);
console.log('Number format:', numFormat);

Confirm that:

1. Timezone matches the expected IANA name
2. UTC offset is correct for the current date (accounting for DST)
3. Locale affects number and date formatting correctly
4. Languages are in the expected priority order
5. All values are geographically consistent with the proxy IP

Configuration safeguards

1. Use IANA timezone names, not UTC offsets. America/New_York handles DST correctly. UTC-5 does not.

2. Set languages in priority order. A user in Germany would typically have de-DE,de,en. Including English as a secondary language is realistic for most regions.

3. Match geolocation to the proxy city, not a street address. City-level precision is sufficient and more realistic than exact coordinates.

4. Keep locale and timezone in the same region. A ja-JP locale with Europe/London timezone is an obvious inconsistency.

5. Let BotBrowser auto-detect when possible. The auto default produces consistent results from the proxy IP without manual configuration.

6. Test formatting behavior, not just API values. Check that toLocaleDateString() and toLocaleString() produce region-appropriate formats.

Regional configuration questions

Does BotBrowser handle DST transitions correctly? Yes. BotBrowser uses IANA timezone names internally, which encode DST rules. Date.getTimezoneOffset() returns the correct offset for any date, including transitions.

Can I set timezone per context in Playwright? Playwright's timezoneId option per context changes JavaScript Intl behavior. BotBrowser's --bot-config-timezone flag applies the timezone across the BotBrowser configuration. Choose one owner for the value and validate the resulting application behavior.

What happens if I use auto-detection without a proxy? Without a proxy, BotBrowser uses your real public IP for auto-detection. The geographic settings will match your actual location.

Can I set just the timezone and let the rest auto-detect? Yes. You can override individual settings. For example, setting only --bot-config-timezone while leaving locale, languages, and location on auto works. However, ensure the timezone is consistent with the auto-detected values.

Does --bot-config-location require user permission? BotBrowser sets the geolocation values that are returned when a page requests geolocation permission. The user permission prompt behavior is controlled by the browser context settings.

What language format does --bot-config-languages accept? A comma-separated list of BCP 47 language tags: en-US,en,fr-FR,fr. The order determines priority, which is reflected in navigator.languages and the Accept-Language header.

Can I use these flags without --bot-profile? The geographic flags work independently, but without a profile, you do not have fingerprint protection. Always use --bot-profile as the foundation.

Does the Accept-Language header update when I set --bot-config-languages? Yes. The Accept-Language header on every HTTP request reflects the configured language list, including proper quality values (q-values) for priority ordering.

Ownership of regional configuration

Assign one owner to the regional policy for each deployment. That owner decides which values follow the proxy, which values come from the profile, and which application requirements justify launch overrides. Without an owner, explicit values tend to accumulate in templates long after their original purpose disappears.

Store the browser release, profile revision, proxy route, and launch overrides as one reviewed unit. These inputs jointly determine the effective regional environment. Recording only the proxy address leaves support unable to explain why a language or timezone came from another source.

Use descriptive deployment fields rather than a single unstructured command string. Separate fields for profile, route, timezone, locale, languages, and location make source priority visible during review. The final launcher may still produce CLI flags, but the maintained record should show which values are deliberate and which remain automatic.

Treat profile configs as versioned product configuration. A profile update can change an effective regional value even when launch flags remain unchanged. Review profile changes with the same application checks used for proxy or browser updates.

Designing a regional policy

Begin with the application requirement. Decide where the user expects dates, numbers, language, and location-sensitive content to be presented. Then choose the smallest set of explicit values needed to meet that requirement.

If all regional values should follow the network route, leave them on auto and keep the route assignment accurate. If the interface language must remain fixed across routes, set that value explicitly and leave unrelated values automatic. If a profile represents a stable locale family, place that value in profile configs so deployments sharing the profile do not repeat it.

Avoid setting the same value in several layers. Although the priority order resolves the result, duplicate values hide ownership. A later change to the lower layer appears to have no effect until the higher override is removed, which can surprise an operator during recovery.

Document exceptions in plain application terms. "Customer portal requires French interface" is useful. "Temporary override" without an owner or review date is not. Remove an exception when the application no longer needs it.

Release validation by outcome

Choose representative profile and route combinations, including any explicit exceptions. Start fresh contexts with the intended release unit. Use normal application pages that display localized dates, numbers, language, or regional content.

Confirm that the observed application result matches the deployment policy. Do not collect unrelated page values simply because they are available. The purpose of the check is to establish that the selected configuration supports the approved workflow.

For a multi-context worker, validate each assignment independently. One context may receive a launch override while another follows its profile or proxy. A successful first context does not establish that source priority was correct for the rest.

Record the effective policy sources along with the outcome. For each setting, it is enough to note launch, profile, or proxy as the source. This makes a later difference understandable without storing page content or detailed browsing records.

After changing an override, profile, or route, create a new context. Existing contexts may already hold application state associated with the earlier region. A fresh context provides a clear release boundary.

Rollback and unexpected results

Keep the last reviewed release unit available through the rollout. If the application presents an unexpected region, first compare launch values, profile configs, and route assignment with the approved record. This source-order review often identifies a stale override or wrong profile without broader investigation.

Restore the previous unit before changing several fields. Removing an override while also changing the profile and proxy destroys the baseline. Once the application check passes on the previous unit, introduce the next change through the staged rollout.

Separate regional configuration problems from destination availability. A site may return different content because its own service changed. Repeat the approved check with the known release unit before concluding that BotBrowser priority changed.

Include scheduled maintenance in the same review cycle. Proxy inventories, profile packages, and application language support evolve at different times. A periodic check can confirm that each explicit override still has an owner, each profile remains assigned to an active workflow, and each automatic value still follows the intended route family. Remove obsolete configuration instead of carrying it forward as a precaution. The resulting templates are shorter, source priority is easier to understand, and a future release has fewer stale values to audit.

Maintaining regional alignment

Timezone, locale, language, and geolocation form the regional layer of a browser profile. Settings left on auto follow the documented priority order and selected proxy route. For specific requirements, --bot-config-timezone, --bot-config-locale, --bot-config-languages, and --bot-config-location provide explicit control. See the features page for identity controls, or explore solutions for multi-region deployment strategies.

For proxy setup, see Proxy Configuration. For browser identity, see Browser Brand Switching and User Agent Control and Client Hints. For multi-region workflows, see Multi-Account Browser Isolation.