Timezone Leak: Your VPN Moves Your IP, Not Your Clock

You switch on a VPN, pick a server in Amsterdam, and load a page. Your IP address checks out as Dutch on every IP-checking site you try. And yet the checkout adds an extra verification step, the streaming catalog stays wrong, or a login triggers a “new device” email. What gave you away fits in one line of JavaScript: Intl.DateTimeFormat().resolvedOptions().timeZone.

That call returns the timezone your operating system is set to, and a VPN has no influence over it whatsoever. Your packets now come from Amsterdam; your browser still cheerfully reports America/New_York. The widget on this page runs the same comparison a fraud script would: it looks up the timezone your IP address implies, reads the timezone your browser reports, and checks whether the two agree.

Two answers to one question

The first answer comes from the network. A website sees the IP you connect from and looks it up in a geolocation database: ipinfo.io, MaxMind and their competitors all return a timezone with the location. With a VPN on, that answer points at the exit server: connect through Amsterdam and the database says Europe/Amsterdam. How those databases are built, and how wrong they can be about your street address, is a story we covered in our IP geolocation article. But at timezone granularity they are almost never wrong.

The second answer comes from your operating system. JavaScript has been able to read the local UTC offset since the nineties through new Date().getTimezoneOffset(), and modern browsers hand over the full IANA zone name through the Intl API. No permission prompt, no user gesture, nothing logged in any privacy dashboard. It is treated as ordinary metadata, the same class of thing as your screen size.

One visitor, two answers

What your packets say

VPN exit IP 198.51.100.7 → geo database → Europe/Amsterdam

What your browser says

OS clock settings → Intl.DateTimeFormat() → America/New_York

Mismatch

Europe/Amsterdam ≠ America/New_York — caught by one string comparison, before you have clicked anything.

Comparing the two is free, so everyone who has a reason to does it: payment fraud scoring, streaming region enforcement, ad-fraud filters, account security systems, and the anti-bot stacks that already run a dozen other consistency checks.

Why the VPN can’t fix this

A VPN encrypts your traffic and swaps the IP address that servers see. That is the entire job description. Your timezone never travels through the tunnel because it never travels at all. It sits in your OS settings, and the browser reads it locally and reports it to any script that asks.

The site does not learn your clock time; it learns the zone identifier. America/New_York is a location claim, accurate to a vertical strip of the planet, and it sits in plain sight next to navigator.language and the Accept-Language header, which make the same kind of claim about where you live.

To be fair, a mismatch proves nothing on its own. People fly with laptops that still think they are at home, and remote workers keep their team’s timezone on purpose. Detection systems know this, which is why the mismatch feeds a risk score instead of triggering a ban. But scores add up: a timezone mismatch plus a datacenter IP plus a WebRTC leak is no longer ambiguous, and each signal makes the next one count for more.

The half-spoof trap

The obvious fix is to lie about the timezone too, and there is a pile of extensions offering to do exactly that. Most of them override Intl.DateTimeFormat so that resolvedOptions().timeZone returns whatever you configure. The problem is that your browser announces its timezone in more places than one:

• new Date().getTimezoneOffset() reports how many minutes your clock is behind UTC, from a completely different code path.
• Date.prototype.toString() spells the zone out in words: “GMT-0400 (Eastern Daylight Time)“.
• Formatting a date for an arbitrary day of the year exposes your daylight-saving rules, which are part of the zone’s identity.

A fixed offset is not a timezone. Amsterdam is UTC+2 in July but UTC+1 in January, and it switches on different dates than New York does: the EU changes clocks on the last Sunday of March, the United States two or three weeks earlier. A script can ask what your offset was on the first of January and the first of July and check whether the pair matches the zone you claim. A spoof that pins one offset year-round matches no place that ever changes its clocks, and certainly not the Amsterdam it claims to be.

Miss any of these and the browser starts arguing with itself:

VPN only VPN + timezone extension Everything aligned

IP timezone (geo lookup) from the VPN exit

Europe/Amsterdam

Intl.DateTimeFormat() claim straight from the OS

America/New_York

Clock offset right now via getTimezoneOffset()

UTC−4

Mismatch

The IP says Amsterdam, the browser says New York. Reads as a VPN or proxy.

There is a second layer to this trap. An overridden Intl.DateTimeFormat no longer looks native when a script inspects its source. It is the same patched-function tell that exposes stealth plugins, the one we walked through in the bot detection article. A clean mismatch says “probably a VPN”. A patched API says “this person is actively manipulating the browser”, and every serious scoring system prices that higher.

What to actually do

1. Test before you trust. The widget on this page compares your browser’s timezone against your IP’s right now, and the full browser scan runs it alongside the WebRTC, platform and fingerprint checks. Run it with the VPN on. If the widget flags you, so does every fraud script.
2. Move your clock with your VPN. The boring fix is the solid one: set your OS timezone to the exit city before you connect. There is nothing to detect, because nothing is fake: every API reports the same zone from the same source. The privacy-crowd alternative is Tor Browser, which reports UTC for everyone; your real zone stays hidden, at the price of looking exactly like Tor Browser.
3. If you run multiple identities, stop doing this by hand. Managing accounts across regions means every profile needs its own IP, timezone, language and fingerprint, all agreeing with each other, every session. That bookkeeping is what anti-detect browsers automate: Incogniton derives each profile’s timezone from its proxy IP, so the two answers from this article never disagree in the first place.

The timezone check is the cheapest geolocation cross-check a script can run, which is exactly why it is everywhere. Thirty seconds with the widget above tells you which side of it you are on.