Time zone, language and IP: how a site notices you're pretending

Someone on a Japanese exit node, with the system time zone set to Shanghai and the browser in Simplified Chinese. A website needs no clever analysis; put those three facts side by side and the story tells itself. That won't necessarily get you blocked, but it goes into a score. What follows is what exactly gets compared, and which inconsistencies you can live with.

Inferring a time zone from the IP

Once the server has your IP it looks it up in a GeoIP database (MaxMind, IPinfo and friends) and gets a country, region, city and, as a bonus, a time zone name such as Asia/Tokyo. At country level this is quite reliable; at city level, much less so, since databases routinely tag whole blocks of data-centre addresses with the operator's registered location.

With an IP time zone in hand, the server can compute "what time should it be right now, there". That step matters later.

The time zone the browser reports

Page JavaScript has two sources:

• Intl.DateTimeFormat().resolvedOptions().timeZone returns an IANA zone name, e.g. Asia/Shanghai.
• new Date().getTimezoneOffset() returns the difference between local time and UTC in minutes; Beijing time gives -480.

In a normal browser these are two expressions of the same system setting and always agree with each other. Their relationship to the IP time zone is another matter: IP in Tokyo (UTC+9), JavaScript says Shanghai (UTC+8), one hour apart.

Daylight saving is an easy trap. America/Los_Angeles has an offset of 480 in winter and 420 in summer. Sites compare using today's date, so a tool that changes the zone without handling DST slips up in particular months.

The clock itself

Beyond the zone, you can compare the time. The server knows the current instant in the IP's time zone; the page sends back new Date(); subtract. A few seconds of difference means the system clock is synced. Ten-plus minutes means either the clock never syncs (common on old virtual machines) or the zone and the clock were changed separately. Our authenticity score takes a small deduction for drift over three minutes. Small, because ordinary people's clocks drift too.

Language: three places, three answers

Language leaks from three places, and they don't live at the same layer. The Accept-Language request header goes out with every request, visible to the server directly, and looks like zh-CN,zh;q=0.9,en;q=0.8. navigator.language and navigator.languages are what page script reads, normally the same setting as the header. And the default Intl locale, e.g. new Intl.NumberFormat().resolvedOptions().locale, reflects the system or browser region and is used when formatting numbers and dates.

In a genuine browser the three are highly consistent: not byte-identical, but from the same origin. A primary Accept-Language that differs from navigator.language is one of the heavier deductions on this site, because it almost only happens when someone edited one of them by hand.

Two examples

IP in Japan, time zone Asia/Shanghai, language zh-CN. The archetypal "Chinese user through a Japanese node". Two of three signals say China, one says Japan. Most sites won't stop you for this: the combination is far too common, and it's honest. You haven't faked anything; your traffic just took a detour. It gets logged, it may nudge recommendations or a risk score, and that's about it.

IP in the US, time zone America/Los_Angeles, language zh-CN, a font list full of Chinese fonts. For a Chinese speaker living in Los Angeles this is completely ordinary. To a risk model it overlaps heavily with "domestic user who changed their time zone", so it may trigger extra verification more often than the first case. The irony: the harder you work to make the time zone match the IP, the more it looks like a disguise, unless language, fonts and keyboard layout move with it.

Mistakes anti-detect browsers keep making

"Fingerprint browsers" or anti-detect browsers sell the promise that each profile looks like a different real person. They stumble in predictable places:

• The JavaScript time zone changes but Accept-Language doesn't, or the reverse.
• Intl's timeZone is overridden but getTimezoneOffset() still returns the old value, so two APIs contradict each other.
• The zone changes but the system time doesn't, so the clock drift computed against the IP zone is exactly a whole number of hours.
• The language list is unnatural: en-US, zh-CN with no plain zh, or one entry in Accept-Language and five in navigator.languages.
• Only the browser-visible values change; the HTTP layer, Client Hints included, is untouched.

What these have in common is partial modification. Risk systems are acutely sensitive to it, because it almost never occurs among real users.

Advice for people using circumvention tools

Don't chase a perfect disguise; that's a different industry's problem. What you need to know is simpler: a time zone that disagrees with the IP is the natural consequence of using a proxy, sites see it constantly, and our authenticity score deducts only lightly for it. What gets punished hard is outright fakery: a user agent that doesn't match the engine, navigator.webdriver set to true, two canvas draws that differ. Leave the browser alone and put the effort into choosing a decent tool instead of fiddling with time zones.

To see your own three time zone values and three language values, run the time zone check.

FAQ

Would setting my system time zone to match the exit node make me safer? Usually not. Unless language, system clock, fonts and Client Hints move together, you've swapped one inconsistency for another, and the new one looks more like a disguise.

The IP time zone says Guangzhou but I'm in Shenzhen. Does that matter? No. GeoIP city accuracy is limited anyway, and sites compare time zones, not cities. Both are Asia/Shanghai.

Does setting my browser to English have any effect? No deduction, as long as the header and JavaScript agree. Plenty of developers in China run all-English environments. The only effect is which language a site serves you by default.