時區不一致：網路上成本最低的一致性檢查
在網站能執行的所有一致性檢查中，比對時區的成本最低。它只需要一次 JavaScript 呼叫，加上伺服器本來就會做的一次查詢。它也是帳號被多看一眼最常見的原因之一。
兩個時區，兩個來源
第一個時區來自你的位址。伺服器知道請求來自何處，並用地理定位資料庫將該位址對應到一個地區及其時區。巴黎的連線對應的就是 Europe/Paris。這發生在伺服器端，你的瀏覽器無從置喙。
第二個來自你的瀏覽器。Intl.DateTimeFormat().resolvedOptions().timeZone 會回傳作業系統所設定的 IANA 名稱，而 new Date().getTimezoneOffset() 則回傳目前與 UTC 的位移。如果機器設定為柏林，網頁看到的就是 Europe/Berlin，不論封包來自何處。
為什麼兩者會不一致
正當的原因包括旅行、從未更改時鐘地區的筆電，以及從另一個國家出口的企業網路。網站在意的原因則是代理：瀏覽器在某個國家，卻使用另一個國家的位址，而沒有人想到時鐘。巴黎與柏林的位移相同，所以光看位移是相符的；但 IANA 名稱並不相符。比對名稱的檢查就能抓到這一點，這就是為什麼診斷工具會同時顯示瀏覽器的名稱與位址的名稱，而不是數值位移。
不一致代表什麼
單獨來看，並沒有定論。許多真實的人都會觸發這種情況。但它是一個低成本的訊號，而評分系統會把這些低成本訊號加總起來。時區不一致，加上被分類為主機代管的位址，再加上位於第三個地點的 WebRTC 候選位址，與單純的時區不一致，是完全不同的情況。
讓兩者一致
要得到一致的結果有兩種方式。一是把作業系統的時區設成與位址相符，這可行，但當多個設定檔使用不同位址時就很麻煩。另一種是讓瀏覽器設定檔覆寫它所回報的時區，這正是專用瀏覽器的做法：設定檔的時區會跟隨它啟動時所用的位址，因此兩個名稱會自動相符。第二種做法還必須涵蓋目前的位移、夏令時間的轉換，以及在地化的日期字串，因為腳本可以把這些全部拿來比對。一個回報 Europe/Paris、卻以柏林的位移格式化日期的設定檔，只是把矛盾搬了個地方。
在報告中該看什麼
一個把「依 IP 判定的時區」與「時區」並排顯示，並在兩者不同時標記出來的診斷工具，做的正是網站檢查會做的事。如果兩者相符，檢查就通過；如果不符，你就知道該改哪一個。無論哪種情況，有用的都是比對本身，而不是附加在上面的分數。
