Does your visitor's clock agree with their IP address?

Written by Claude (AI) · research signals and editing by Nathan Pankowsky · see AI usage at the end

This follows up 98% of your visitors share a clock. That post compared each visitor's clock with the country the site sells to. This one compares it with the country of the visitor's IP address.

On three small sites, 2,918 visitors had both a device time zone and an IP location. For 39% of them the two didn't agree. Almost all of those were on datacenter addresses: 93% of datacenter visitors had a clock set somewhere else, against 3–4% on mobile networks and on the home lines ipinfo flags as residential proxies. Among visitors who clicked an ad, 3% didn't agree, and most of those were one quirk: Israeli phones set to the West Bank's time zone, which keeps the same time as Israel.

How you compare matters as much as whether you do. Matching zone names flags those phones. Matching UTC offsets lets them through, but it also lets a UTC clock pass on a UK address all winter.

Where the idea comes from

Comparing the browser's time zone with the IP's location is an old check in commercial bot detection. A bot that rents an address in one country may keep the clock of the machine it runs on, which is somewhere else. Castle's engineering blog describes it as a weak signal: a mismatch doesn't prove fraud, but it can add to a risk score (Castle).

Our previous post left it open. In his concluding notes there, Nathan pointed out that IP location doesn't always agree with the time zone the browser reports, and that both readings are easy to spoof: useful for weeding traffic out, not proof that a visitor is real. This post measures how often they disagree, and for whom.

Our data

Three sites we monitor, over two to four days in October 2026. We withhold their names.

• A visitor is an IP address. We use its first page view that recorded both readings. Verified crawlers and self-declared bots are left out.
• The clock is the browser's time zone name (for example Europe/London), read by our script. We don't record the device's actual time.
• The IP location is ipinfo's country for the address. We also use ipinfo's flags for the type of network: datacenter, residential proxy, mobile carrier, VPN, iCloud Private Relay.
• Two ways to compare:
  • Zone list: the clock's zone is one of the zones the public time zone database lists for the IP's country.
  • Offset: the clock's distance from UTC, at the moment of the visit, equals that of one of the country's zones.

The shop gets far more datacenter traffic than the other two, so it dominates the totals. We give per-site figures where that matters.

Result 1: the mismatch is almost all datacenter traffic

Chart: clock and IP country disagree mostly on datacenter addresses. Visitors whose clock zone is not a zone of the IP's country, by ipinfo network type (zone-list method); dashed line: all visitors, 39%. Source: reproduce_clock.py, 2,918 visitors on three sites, 9–14 Oct 2026.

The shop's 82% mismatch is its datacenter traffic. On the store and the lettings site, where most visitors are people on home and mobile lines, the clock and the IP disagreed for 4–5% of visitors.

Paid clicks barely disagree at all. Of the 1,073 visitors who clicked an ad, 36 (3%) had a clock outside their IP's country by the zone list, and only 4 (0.4%) by the offset. The next two sections explain the gap between those numbers.

Result 2: what the mismatches look like

The 1,141 zone-list mismatches fall into a few clear kinds.

The datacenter mismatches are not subtle. Of the visitors whose offset didn't fit, most were five to seven hours off (a New York clock on a European address) or ten to twelve hours off (New York on India, Shanghai on the US East Coast). Only 13 were one or two hours off, which is where a person with a neighbouring zone would show up.

The fourth row matters most for anyone relying on IP reputation. Those addresses carry no datacenter, proxy or VPN flag, yet their clocks sat on another continent. The clock caught what the IP data missed.

Result 3: zone names or UTC offsets?

The two methods disagreed on 72 visitors. In every case the zone list flagged a visitor whose offset fit:

• West Bank time on Israeli addresses (38 visitors, 29 of them ad clicks on the store). Asia/Hebron is the zone the time zone database uses for the West Bank. It keeps Israel's time except around the daylight-saving changes. These are ordinary Israeli store visitors, probably phones that picked their zone from a nearby network. They make up 29 of the 33 ad clicks the zone list flags on the store.
• Shanghai time on Singapore and Hong Kong addresses (23). Same offset, different zone. All 23 were datacenter addresses, so here the zone name told us something the offset didn't.
• A UTC clock on a Portuguese address (2). The offset check passes them because the Azores keep UTC in summer. A clock set to UTC is a strong sign of a server, and the offset check loses it.

ipinfo also returns its own time zone for each address. Matching the clock against that one exact zone is stricter still. It flagged eight more visitors: seven US datacenter addresses whose clock was in another US zone, and one Brazilian visitor, not on a datacenter address, on São Paulo time whom ipinfo placed in Fortaleza, which keeps the same time. The datacenter ones were already suspect for being datacenter traffic, and the Brazilian one is a person, so we compare against all of the country's zones instead.

Neither method is right on its own. Offsets suit people, who pick a neighbouring zone by accident. Zone names suit servers, whose zone is a configuration choice. A practical rule: compare offsets, but treat a UTC or fixed-offset clock as its own signal.

Daylight saving and other traps

Daylight saving is where offset checks usually go wrong. The trap is a fixed table of offsets per country, built once. Offsets have to be worked out from the time zone database for the moment of each visit. For the pairs of IP country and clock in our data:

• 7 pairs, covering 56 visitors, change verdict on some day of the year. A UTC clock on a UK or Irish address (14 visitors) fails the offset check from late March to late October and passes it all winter, when UK time is UTC. West Bank and Israeli time differ on only about two days a year, around the changes (24 October in 2026).
• A table frozen on 11 October disagrees with the live offsets for 15 of our visitors by 27 October, two days after Europe and Israel move their clocks back.
• Zone names are safe from this. A zone list doesn't change with the season.

Three smaller traps:

• Old zone names. Chrome still reports Asia/Calcutta for India, and the time zone files on our analysis server no longer included it. Without an alias list, every Indian visitor on Chrome would count as unknown.
• Fixed-offset zones. One Israeli ad click had its clock set to Etc/GMT-2, which means UTC+2 (the sign is reversed). That matches Israel only in winter. It is probably a person who set the zone by hand.
• More than one clock per address. 12 of the 2,918 addresses reported two or more zones: 6 datacenter and 5 residential-proxy addresses, where several machines or people share one exit. We used the first.

Against our other checks

We also ran our other browser checks on the same visitors. We don't publish what they look at, and this column can't be reproduced from the dataset.

The two mostly agree: the clock check covers 800 of the 844 visitors our other checks flag. That agreement is narrower than it looks. 798 of the 800 were on the shop, and two of our checks account for 796 of them. They look like two automated fleets: one of about 740 addresses, all with New York clocks on European and Indian datacenters, and one of 90 with UTC clocks. The clock check also adds 271 visitors that nothing else flagged: 248 on datacenter addresses and 17 on the unflagged networks above. Without ground truth we can't say how many of those are bots. A New York clock on an Indian datacenter is hard to explain any other way.

On residential-proxy and mobile addresses, both sides were nearly silent. Of 1,003 such visitors, 6 had a clock that didn't fit, and our other checks flagged 3, all inside apps' built-in browsers. That repeats our earlier finding: on those networks, the IP reputation flag on its own says little about the visitor.

Limits

• No ground truth. Agreement between the clock and our other checks is not proof that either is right.
• Short windows, three sites. Two to four days each. The shop's datacenter traffic dominates the totals.
• The clock can be set to anything. A bot that sets its zone to match its proxy passes this check. These numbers describe bots that didn't bother.
• IP location is sometimes wrong, more often for mobile carriers, satellite links and travel eSIMs.
• One reading per address. We used the first page view that recorded both. Twelve addresses reported more than one zone.
• VPN visitors are barely measured. Our script records few readings from visits we mark as VPN, so 8 VPN visitors is not a result.
• Few paid clicks disagreed. 36 by the zone list, 4 by the offset. That is too few to say how those visitors behaved.

What to do with it

1. Use it to weed out, not to decide. On datacenter addresses and networks no one has flagged, a clock from another continent is a strong hint. On mobile and home lines it almost never fires, and when it does it is as likely a traveller as a bot.
2. Compare offsets at the time of the visit, from the time zone database, not from a fixed table. Or keep a zone list per country and add the neighbours that keep the same time (for Israel, Asia/Hebron and Asia/Gaza).
3. Treat a UTC or fixed-offset clock as its own signal. People rarely set one; servers often do. An offset check alone lets it through in UK and Irish winters.
4. Keep the old zone names browsers still report, such as Asia/Calcutta, Asia/Tel_Aviv and Europe/Kiev.
5. Compare with the IP's country, not its city. Inside a large country, IP location is too coarse to argue with the visitor's chosen zone.
6. Don't block paid clicks on this alone. By offset it fired on 4 ad clicks (0.4%). All four came from addresses ipinfo flags as residential proxies, and our other checks flagged none of them: worth a look, not a block.

Try it on your own traffic

Button Solutions scores each paid click per campaign, and the clock-against-IP check from this post is rolling out now. Sign up.

Reproduce it yourself

The scrubbed data and scripts are on GitHub, shared with our previous two posts: ip-quality-reproduction-oct-14-2026. The data has each visitor's IP country, ipinfo's network flags and the browser's time zone. reproduce_clock.py recomputes every figure in this post except the comparison with our other checks. Site names, IPs and click IDs are replaced with random tokens or removed.

The data and scripts are licensed CC BY-NC-ND 4.0: you may share them unchanged for non-commercial purposes, with credit to Button Solutions. If you reproduce or build on these figures, please cite this post and the dataset.

AI usage

This post was researched and written by Claude (Anthropic), with research signals and editing by Nathan Pankowsky. Claude wrote the analysis code and the text; every figure comes from that code.

References

• Button Solutions, 98% of your visitors share a clock: testing a 2018 fingerprinting study on three small stores, October 2026.
• Castle, How to detect a browser's time zone using JavaScript, 2025.
• IANA, Time Zone Database.