使用new Date().getTimezoneOffset()检测时区偶发返回0问题咨询

可能的触发原因 #

• Chrome 94版本V8引擎的Date初始化竞态：该版本Chrome存在极罕见的场景，Date实例初始化完成时，V8还未完成系统时区配置的读取，此时调用getTimezoneOffset()会直接返回默认的0值（UTC时区偏移）。这种情况多出现于浏览器冷启动、系统资源占用过高的场景，无需人工干预，运行时初始化完成后后续调用即可返回正确值，和“重新登录就恢复正常”的表现完全吻合。
• 隐私防护类扩展的临时拦截：部分去追踪、隐私保护类Chrome扩展，会在页面初始化阶段临时篡改时区API返回值为UTC，避免页面刚加载就获取用户真实时区信息，待扩展规则加载完成后会恢复API的正常返回，因此首次登录调用时返回0，二次登录时扩展已完成初始化，返回值正常。
• 代码执行时机过早：如果时区检测逻辑是在head内联脚本中同步执行，早于DOMContentLoaded事件触发，极个别场景下Chrome的国际化运行时还未完成初始化，日期相关API会返回默认配置值。
• 系统时区配置推送延迟：用户刚开机、刚完成时区切换后短时间内，操作系统给浏览器进程推送时区配置的通知存在延迟，此时浏览器读取到的时区偏移就是默认的0值。

最优排查定位方案 #

• 新增关联日志字段：在调用(new Date()).getTimezoneOffset()的同时，同步采集两个数据：Intl.DateTimeFormat().resolvedOptions().timeZone的返回值，以及当前代码执行时间与performance.timing.navigationStart的时间差。如果出现偏移为0的问题时，同时满足时区字符串为UTC、执行时间距页面初始化不足100ms，即可直接定位为V8初始化竞态问题；如果时区字符串为用户当地时区但偏移为0，说明是getTimezoneOffset()API被篡改导致。
• 增加容灾校验逻辑：无需修改现有业务流程，只需要在获取时区偏移后增加校验：如果返回值为0，延迟50ms重试2次，同时对比IntlAPI返回的时区对应的标准偏移值，二者一致才认为校验通过，不一致就取重试后的结果，该方案对性能影响可忽略，基本可以覆盖99%以上的偶发错误场景。
• 定向排查特殊场景：针对上报问题的Chrome 94版本用户，小范围上线调试埋点，检测到偏移为0时，额外上报当前浏览器已加载的扩展ID列表、performance.memory返回的内存占用数据，即可快速验证是否和特定扩展、高系统负载场景强相关。
• 本地复现方案：使用Chrome 94版本，启动时限制CPU使用率为10%，循环执行冷启动浏览器、打开登录页的操作，即可大概率复现初始化竞态导致的返回0问题。

内容的提问来源于stack exchange，提问作者Puschie