时区不一致：网络上成本最低的一致性检查
在网站能运行的所有一致性检查中，比较时区的成本最低。它只需要一次 JavaScript 调用，加上服务器本来就在做的一次查询。它同时也是账号被多看两眼的最常见原因之一。
两个时区，两个来源
第一个时区来自你的地址。服务器知道请求从哪里来，并用地理定位数据库把该地址映射到某个地区及其时区。对于一个巴黎的连接，结果就是 Europe/Paris。这发生在服务器端，浏览器对此毫无发言权。
第二个来自你的浏览器。Intl.DateTimeFormat().resolvedOptions().timeZone 返回操作系统所配置的 IANA 名称，而 new Date().getTimezoneOffset() 返回当前的 UTC 偏移量。如果机器设置为柏林，页面看到的就是 Europe/Berlin，无论数据包来自何处。
为什么会不一致
正当的原因有：出差旅行、笔记本电脑从未更改过时钟所在地区，以及从另一个国家出口的企业网络。网站在意的原因则是代理：浏览器位于一个国家，使用的却是另一个国家的地址，而没有人想到过时钟。巴黎和柏林的偏移量相同，所以光看偏移量是吻合的；而 IANA 名称并不吻合。比较名称的检查能抓到这一点，这就是为什么诊断工具要同时显示浏览器的名称和地址的名称，而不是一个数字偏移量。
不一致意味着什么
单凭它自己，并无定论。许多真实的人也会触发它。但它是一个成本很低的信号，而评分系统会把低成本信号叠加起来。不一致，加上被归类为托管的地址，再加上位于第三个地方的 WebRTC 候选地址，与单独一个不一致，完全是两回事。
让它们保持一致
有两种方法可以得到一致的结果。一是把操作系统的时区设置为与地址相符，这行得通，但当多个配置文件使用不同地址时就很笨拙。二是让浏览器配置文件覆盖它所报告的时区，这正是专用浏览器的做法：配置文件的时区跟随其启动时所用的地址，因此两个名称自动吻合。第二种方法还必须涵盖当前偏移量、夏令时切换以及本地化的日期字符串，因为脚本可以把这些全部比较一遍。一个报告 Europe/Paris 却用柏林偏移量格式化日期的配置文件，只是把矛盾挪了个地方。
在报告中要看什么
一个把“基于 IP 的时区”和“时区”并排显示、并在二者不同时加以标记的诊断工具，做的正是网站的检查所做的事。如果二者吻合，检查就通过。如果不吻合，你现在就知道该改哪一个。无论哪种情况，有用的都是比较本身，而不是附在它上面的某个分数。
