Your proxy exits in Frankfurt. Your browser says Asia/Shanghai. To a website those two facts arrive in the same request, and together they tell a story that no ordinary visitor tells: a person whose network is in Germany while their computer's clock is set eight hours ahead. This guide covers how a site reads your timezone, the five reasons it disagrees with your IP, and what to change so the two describe the same place.
How a website reads your timezone
No permission prompt is involved. Two lines of JavaScript do the job:
Intl.DateTimeFormat().resolvedOptions().timeZone; // "Asia/Shanghai"
new Date().getTimezoneOffset(); // -480 (minutes behind UTC)
The first returns the IANA zone name your operating system is set to. The second returns the offset for the current date, which changes with daylight saving time. Sites read both, because a spoofed zone name that forgets to adjust the offset is easy to spot.
The IP half comes from a geolocation database. The site looks up the address that made the request, gets a country, a region and the zone that region uses, and compares. When the browser zone and the IP zone describe the same place, nothing happens. When they do not, most risk engines treat it as the single strongest hint that a proxy or VPN is in use, because almost nobody changes their computer clock when they travel through a tunnel.
Five reasons they drift apart
| What you see | Likely cause | Where to fix it |
|---|---|---|
| Browser zone is your home, IP is the proxy country | The operating system clock never changed | OS settings or the browser profile |
| Same country, different zone | A wide country with several zones (the US, Russia, Australia) | Match the proxy's city, not just its country |
| IP zone looks wrong for where the proxy is | The geolocation database is out of date | Change proxy, or accept the lookup's view of it |
| Zone flips between sessions | Automatic timezone updates on a laptop, or a VPN that changes exits | Pin the zone and the exit |
| Zone is UTC | A server, a container or an automation setup | Set a real zone |
1. The clock stayed at home
This is the everyday case. You added a proxy to the browser or to the system, but the system clock still runs on your local zone. Every site now sees a German IP with a Chinese clock. The fix is either to change the operating system zone for as long as you use that proxy, or to use a browser profile whose zone is set independently of the OS.
2. Right country, wrong zone
A US proxy in Los Angeles with a browser set to America/New_York is a three-hour mismatch inside one country. Many risk systems compare at the level of the zone or the offset, not the country, so "roughly right" is still a difference. Pick the zone of the city the exit is in.
3. The database is wrong, not you
IP geolocation is a best guess maintained by commercial databases. Mobile carrier ranges, freshly reassigned datacenter blocks and some residential ranges are placed in the wrong city, occasionally the wrong country. If two lookup services disagree about your proxy, the sites you visit will disagree too. There is nothing to fix on your side except to choose a proxy that the major databases place where it really is.
4. Something keeps changing it
Laptops with "set timezone automatically" enabled update the zone from location services and Wi-Fi hints, which can flip the zone in the middle of a session. Some VPN apps rotate exits without telling you. In both cases yesterday's consistent setup is inconsistent today, and the history of changes is itself visible to any site you were logged into throughout.
5. Everything is UTC
Servers, containers and headless automation often run on UTC because nobody set anything else. Real people almost never live on UTC. A UTC zone paired with a residential IP is a classic sign of a script, not a person.
Setting the zone name is only half the job. getTimezoneOffset() must return the right value for the date, including daylight saving changes. A browser that reports Europe/Berlin in July but an offset of −60 has told the site it is lying.
How to check it properly
- Open the Lab with the proxy you actually use. The timezone row shows the zone your browser reports and the zone your IP resolves to, side by side.
- Read the language row as well. A German IP, a German zone and a browser whose only language is
zh-CNis still an unusual combination. - Change one thing, then check again. If you change the proxy and the OS zone at the same time you will not know which one fixed it.
- Repeat after a laptop wakes from sleep or a VPN reconnects, because those are the moments the zone tends to move.
Check your own timezone result
The Lab compares the zone your browser reports with the zone of your IP, and shows the language and offset next to it.
How to fix it
For one identity, occasionally: change the operating system timezone to the proxy's city while you use it, and change it back afterwards. Restart the browser, because some browsers cache the zone at startup.
For one identity, permanently: if the proxy is always the same, leave the OS on that zone and set the language and keyboard to match. The cheapest consistent setup is the one you do not have to remember.
For several identities: the OS clock cannot be three places at once. Each browser profile needs its own zone, its own language list and its own proxy, and those three have to be set from the same source so they cannot drift apart. This is the point where a general-purpose browser stops being enough.
What not to do: do not set the zone to UTC to "stay neutral", and do not install an extension that fakes Intl while leaving Date alone. Both produce a browser that is internally inconsistent, which is worse than a browser that is consistently in the wrong place.
What this means when you run more than one account
Timezone is the cheapest cross-check a platform can run, so it runs on every request. Five profiles behind five proxies in five countries, all reporting the same home zone, are five accounts wearing the same wristwatch. The link is made before any of them does anything suspicious.
The rule is the same as for WebRTC: every signal that describes a location has to describe the same one. IP, timezone, offset, language and geolocation are one story or they are evidence.
How Mango Browser handles the timezone
Each Mango profile has its own timezone setting with two modes: follow the exit IP of the bound proxy, which is the default, or a fixed zone you choose. In both modes Date, Intl and the offset report the same zone, with daylight saving applied for the date, so the two lines of JavaScript above always agree with each other.
Language works the same way. It follows the exit IP by default (a Singapore proxy gives en-SG), or you set a fixed list, and the Accept-Language header, navigator.languages and the Intl locale are set together. Geolocation can follow the exit IP too. Switch the proxy on a profile and its location story switches with it, without touching the operating system clock.