still cooking_
5 min read

How to Override Your Timezone in Chrome for Testing (And Why It's Not Enough)

How to Override Your Timezone in Chrome for Testing (And Why It's Not Enough)

How to Override Your Timezone in Chrome for Testing (And Why It's Not Enough)

While debugging a timezone bug in a calendar booking feature, I needed to simulate what a user in Tokyo or Istanbul would see — without restarting my machine or changing my OS settings. Chrome DevTools has a built-in way to do this, and it's genuinely useful. But it also has some serious limitations that every developer should know about before relying on it.

Here's a quick breakdown of how it works, when to use it, and when it will silently mislead you.

The Bug That Led Me Here

I was building a booking calendar where users could select a date and see available time slots. The slots were stored with Berlin-local timestamps (e.g. 2026-03-16T11:30:00+01:00), and everything looked fine when I tested it locally.

Then I realised: what does a user in Turkey see when they click March 16?

The short answer is — no slots. The calendar would show March 16 as unavailable, even though there was clearly a slot at 11:30 AM. The reason was that react-day-picker passes a Date object set to midnight in the user's local timezone. For a user in Turkey (UTC+3), midnight on March 16 is actually March 15 at 21:00 UTC, which when converted to Berlin time is still March 15. So the code was looking up the wrong key in the data entirely.

To confirm this, I needed to simulate being in a different timezone — without touching my OS clock.

How to Override Timezone in Chrome DevTools

Chrome lets you override your timezone on a per-tab basis using the Sensors panel. Here's how:

Step 1: Open DevTools with Cmd + Option + I (Mac) or F12 (Windows/Linux).

Step 2: Open the command palette with Cmd + Shift + P (Mac) or Ctrl + Shift + P (Windows/Linux).

Step 3: Type sensors and select "Show Sensors" from the list.

Step 4: In the Sensors panel, scroll down to the Location section. You'll see a timezone dropdown — change it to whatever you want to test, for example Asia/Tokyo or Europe/Istanbul.

Step 5: Refresh the page. This is important — the override only takes effect on load for most frameworks.

That's it. Your browser tab now reports a different timezone to JavaScript via the Intl API.

What This Override Actually Changes

The Chrome sensors override affects:

  • Intl.DateTimeFormat().resolvedOptions().timeZone — the timezone string your app can read
  • Formatting via Intl.DateTimeFormat — dates formatted using the Intl API will reflect the overridden timezone
  • toLocaleDateString() and toLocaleTimeString() when called with an explicit timeZone option already set

What It Does NOT Change (The Limitations)

This is the critical part. The override is shallow. It does not affect:

new Date(year, month, day) — This constructor always uses the real OS timezone. So if a library like react-day-picker creates a date using new Date(2026, 2, 16), it will use your actual system timezone, not the overridden one.

Date.getTimezoneOffset() — This returns your real OS offset, not the simulated one. A lot of timezone detection logic relies on this.

new Date().getHours(), .getDate(), .getFullYear() — All local date methods use the real OS timezone.

Node.js / SSR code — The DevTools override only affects the browser tab. Any server-side code runs with the server's timezone, completely unaffected.

In Practice

This means that if your bug lives in how a library constructs Date objects from user interaction (like a calendar click), Chrome's timezone sensor will not reproduce it. I ran into this exactly — setting DevTools to Tokyo still showed March 16 working fine, because react-day-picker was using the real OS timezone to build the date object.

Better Alternatives for Deep Timezone Testing

If the DevTools sensor isn't enough, here are your real options:

Change your OS timezone temporarily — On Mac, you can change it in System Settings → General → Language & Region → Time Zone. You usually don't need to restart, just reopen your browser. Takes 30 seconds.

Write a unit test with a fixed UTC timestamp — Construct the problematic Date manually:

// Simulates what react-day-picker gives a user in Tokyo clicking March 16
const tokyoMidnight = new Date('2026-03-15T15:00:00Z'); // midnight Tokyo = March 15 UTC
console.log(toBerlinDateKey(tokyoMidnight)); // should log "2026-03-16", logs "2026-03-15" ❌

This is the most reliable way to confirm timezone bugs without any environment changes.

Use a VM or ask a remote colleague — If you need a real end-to-end test with a fully different timezone, a virtual machine with its own clock or a colleague in a UTC+3+ timezone is your most realistic option.

Summary

Chrome's timezone sensor in DevTools is a handy tool for testing display logic and Intl-based formatting. But it's not a full timezone simulation — it doesn't touch the underlying Date object behaviour that most libraries and bugs actually depend on. Don't let it give you a false sense of confidence that your app works across timezones. For that, you need either a real OS timezone change or a well-crafted unit test.