Time & Timezone · Network Tests
Timezone & Clock Test
Check your timezone, clock and DST state against the network you are coming from.
Your clock and timezone
Browser clock vs network clock
The zone name, the offset, the January and July offsets and the two clocks are all computed in your browser from the IANA timezone database your operating system ships. The network column comes from one IP lookup and shows the zone the address is registered in, which is a property of the address rather than a fact about you. The times tick live on this page and nothing is stored or sent.
On this page
What your timezone actually is
Your browser does not store a timezone as a number. It reads an IANA name from the operating system, such as America/New_York, and the offsets and daylight-saving rules for that name come from a database the system ships and updates. The name is the answer; the offset is something the browser works out from it.
That distinction matters because the offset changes. Zones run from UTC-12:00 to UTC+14:00, and a handful sit on thirty- or forty-five minute steps — Kathmandu is UTC+05:45 and Lord Howe moves between +10:30 and +11:00. A page asking "what time is it where you are" gets a different answer in January than in July even on the same machine, which is why the panel above shows the January and July offsets next to the current one.
Two clocks, one machine
The zone and the offset are one pair of values; the system clock is another. A page can read both, which is what makes it possible to catch a spoofed zone that was never applied to the clock.
Reading the panel
The panel above mirrors what a time-information service shows you, and every row is read or derived live in the browser.
- Zone name. The IANA identifier your system reports, or Not exposed in the rare case the API is unavailable.
- Local time and UTC time. Both are the same instant, displayed in two zones, and both tick every second.
- GMT offset. The current offset written the way people usually ask for it, such as GMT+05:00, plus the raw number of minutes so you can see the half-hour zones.
- Daylight saving. Whether the zone is currently shifted, derived from the January and July comparison below it.
- Network column. The timezone attached to your IP address by the registry, and the local time in it, which is the value a website would compute without asking your browser anything.
The IP address test shows the same lookup in a different light if you want the location rather than the clock.
Daylight saving
Daylight saving is the reason a timezone is more than an offset. By asking for your zone's offset in mid-January and mid-July, the panel can tell whether the zone shifts at all and, if it does, which of the two figures is standard time — always the smaller one, since summer moves clocks forward rather than back.
That gives a plain answer to whether daylight saving is in effect right now: the current offset is compared with the standard one. A zone that reports the same offset in both months never shifts, which is the case for most of Asia and Africa, and it is why the row reads "this zone never shifts" rather than a guess about a rule that does not exist.
Two details are worth knowing. Some countries change their daylight rules at short notice, and the browser only follows them once the operating system's copy of the timezone database is updated. And southern-hemisphere zones run this the other way round, so the panel compares rather than assumes — it never decides based on the month.
Why a timezone mismatch gives you away
A timezone is a strong signal precisely because it is boring. Almost nobody sets their clock to a country they are not in, so when the address your traffic comes from sits in one zone and the browser reports another, the pair is unusual. Consistency checks run by anti-fraud systems treat that as a cheap, high-value tell, because it needs no database and no permission.
The signal gets stronger when the two values are combined. A zone name that matches the network while the reported offset does not is the fingerprint of an override applied in JavaScript alone. A clock that differs from the network time by an exact number of hours suggests a device set by hand. And a locale, a timezone and an IP country that point at three different regions is a pattern no ordinary visitor produces.
Where this appears in the wild
The proxy and VPN detection test weighs this row alongside the ASN and the WebRTC addresses, and the home scan folds it into a single consistency score.
Getting the two to agree
Work out which of the two values you actually want to change, because they are not interchangeable. If the goal is for a site to believe you are somewhere else, changing the browser timezone alone rarely holds up — the clock behind it, the locale, the keyboard layout and the language you accept all tend to disagree.
- Leave it alone if you travel. A mismatch after crossing a border is normal and resolves when the device picks up the new network.
- Fix the clock first. Set the device to update its time automatically from the network, then check the zone is right for where you actually are.
- Do not half-spoof. Changing the zone name without the offset, or the offset without the clock, produces a combination that no genuine device shows and is easier to flag than the original.
If your aim is to look ordinary rather than to hide, the fingerprint test shows the rest of the surface a site can read, and the IP geolocation test shows how closely the location attached to your address matches the one your browser reports.