Timezone, Locale, and Language Configuration for Cloud Browsers

Introduction

Geographic consistency is one of the most commonly tested aspects of browser identity. Detection systems cross-reference your IP address geolocation with your browser's timezone, language preferences, and locale settings. Any mismatch is a strong signal that something is unusual.

BotCloud automatically aligns geographic settings to your proxy location, but understanding how this works helps you configure sessions for specific requirements.

Geographic Signals

Timezone

JavaScript exposes the timezone through multiple APIs:

Intl.DateTimeFormat().resolvedOptions().timeZone
// "America/New_York"

new Date().getTimezoneOffset()
// 300 (minutes offset from UTC, negative for east of UTC)

new Date().toLocaleString()
// Formatted according to timezone

Language

Browser language appears in multiple places:

navigator.language      // "en-US"
navigator.languages     // ["en-US", "en"]

And in HTTP headers:

Accept-Language: en-US,en;q=0.9

Locale Formatting

Locale affects how numbers, dates, and currencies are formatted:

(1234.5).toLocaleString()          // "1,234.5" (US) vs "1.234,5" (Germany)
new Date().toLocaleDateString()    // "3/19/2026" (US) vs "19.03.2026" (Germany)

Common Mismatches

Proxy Location	Timezone	Language	What Can Go Wrong
US East	America/New_York	en-US	Setting Europe/London timezone
Germany	Europe/Berlin	de-DE	Leaving language as en-US
Japan	Asia/Tokyo	ja-JP	Using US date formatting
Brazil	America/Sao_Paulo	pt-BR	Setting UTC timezone

Automatic Configuration

When you specify a proxy in BotCloud, geographic settings are automatically derived from the proxy's IP geolocation:

// Proxy in New York - timezone, language, locale auto-configured
const browser = await puppeteer.connect({
  browserWSEndpoint:
    'wss://bots.win/ws?apiKey=YOUR_API_KEY&proxy=socks5h://user:pass@ny-proxy:1080',
});

The session automatically gets:

• Intl.DateTimeFormat().resolvedOptions().timeZone = "America/New_York"
• navigator.language = "en-US"
• Accept-Language header matching the region
• Date and number formatting consistent with the locale

DST Handling

Daylight Saving Time (DST) is a common source of timezone bugs. BotCloud uses IANA timezone names (e.g., "America/New_York") rather than fixed UTC offsets, ensuring correct DST transitions throughout the year.

A timezone set to "UTC-5" is wrong for half the year in New York (which switches to UTC-4 during DST). Using "America/New_York" handles this automatically.

Multi-Region Workflows

For automation targeting multiple geographic regions:

const regions = [
  { name: 'US', proxy: 'socks5h://user:pass@us-proxy:1080' },
  { name: 'EU', proxy: 'socks5h://user:pass@eu-proxy:1080' },
  { name: 'APAC', proxy: 'socks5h://user:pass@asia-proxy:1080' },
];

for (const region of regions) {
  const browser = await puppeteer.connect({
    browserWSEndpoint:
      `wss://bots.win/ws?apiKey=YOUR_API_KEY&proxy=${encodeURIComponent(region.proxy)}`,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');

  // Each session has timezone, language, and locale matching the proxy region
  const tz = await page.evaluate(
    () => Intl.DateTimeFormat().resolvedOptions().timeZone
  );
  console.log(`${region.name}: ${tz}`);

  await browser.close();
}

Best Practices

1. Always use proxies with cloud browsers - Without a proxy, geographic settings have no IP to match
2. Use IANA timezone names rather than UTC offsets to handle DST correctly
3. Verify geographic consistency after configuration by checking timezone, language, and locale together
4. Consider secondary languages - Many users have multiple languages (e.g., ["en-US", "en", "es"])