做前端时间类功能的时候，有个问题绕不开：JavaScript 怎么读取浏览器当前所在的时区。这个需求看起来简单，真上手做会发现坑不少——getTimezoneOffset()只能拿到分钟偏移量，时区名和夏令时处理全是历史包袱；换个浏览器，同一套代码取到的结果可能都不一样。我这两年做过几个带预约排期、会议提醒功能的后台系统，每次都被时区问题绊一下，后来把这块彻底捋清楚了，写篇文章完整分享一下。
1. 先说痛点：为什么浏览器时区获取不是一件简单的事
很多开发者一上来就写new Date().getTimezoneOffset()，拿到的确实是当前时区相对 UTC 的分钟差。但这东西有几个很实际的问题，我在项目里都踩过。
1.1 直接改服务器时区？服务器时区不等于用户时区
早期做过一个简单方案：让后端把服务器时区传给前端，页面直接用。QA 环境测得好好的，一上线就有用户反馈预约时间差了八个小时，因为公司服务器部署在海外，而用户全在国内。这个设计从根本上就错了——你拿到的永远是服务器的时区，不是用户浏览器的时区。
更微妙的情况是：同一个用户，早上用公司电脑（系统时区设置为 UTC+8），晚上用自己的笔记本（时区设置为 UTC-4），服务器永远无从得知。浏览器是唯一能感知用户本机时区设置的地方，所以这个信息必须从前端拿。
1.2 getTimezoneOffset() 的三个老问题：分钟偏移、夏令时、时区名缺失
先看getTimezoneOffset()代码：
const offset = new Date().getTimezoneOffset(); console.log(offset); // 例如中国标准时间返回 -480 // 注意：这个值表示的是 UTC 减去本地时间，所以东八区是负数 -480问题一：返回值是分钟不是小时，而且符号反直觉。东八区返回 -480，北美东部时间返回 300 或 240（取决于是否夏令时）。很多初学者不知道要除以 60，更不知道要取反才是 UTC 偏移。
问题二：夏令时会让偏移量在不同季节变化。同一台设备，1 月份调用的结果和 7 月份就可能不同。如果你想拿“时区偏移”来标记用户所在区域，那同一个用户在一年内会得到两个不同的值，后端存储和展示都会出问题。
问题三：纯粹拿不到时区名。偏移量只能告诉你“跟 UTC 差了几个小时”，但世界上存在多个时区共享同一偏移量，比如 UTC+8 的区域包括中国、马来西亚、新加坡、台湾等，一个偏移量根本无法定位到具体城市或国家。你要做“显示用户所在地时区名”这种需求，靠偏移量是写不出来的。
这几个问题叠加起来就很头疼：想用偏移量做判断，夏令时一变就错；想用偏移量反推时区名，又不具备可行性。所以项目里真正该做的是用标准化时区标识，也就是 IANA 时区数据库里的名称，比如Asia/Shanghai、America/New_York这种。
2. 正路：Intl.DateTimeFormat 与 resolvedOptions 拿到标准时区名
ECMAScript 的Intl对象提供了完整的国际化能力，其中Intl.DateTimeFormat有一个resolvedOptions()方法，能告诉你当前环境实际的时区标识，这才是真正的高级 API。
2.1 一行代码拿到 IANA 时区标识
const timeZone = Intl.DateTimeFormat().resolvedOptions().timeZone; console.log(timeZone); // 例如 "Asia/Shanghai"就这么一行。不需要传任何参数，直接调用Intl.DateTimeFormat()默认会按当前运行环境来解析，resolvedOptions()返回的timeZone字段就是完整的 IANA 时区标识。
如果是 UTC 环境，返回的是"UTC"，这个字符串也是合法的 IANA 时区名。如果浏览器因为某些原因拿不到时区信息（极少数精简版内核），可能返回undefined，需要兜底逻辑。
这个 API 的原理是：Intl.DateTimeFormat在构造时，会根据宿主环境的默认时区（也就是操作系统的时区设置）来绑定一个 IANA 时区标识。resolvedOptions()会把内部解析后的所有配置返回给你，其中就包括浏览器最终选用的timeZone。
2.2 为什么 IANA 名称优于时区偏移：夏令时与政治历史变更案例
IANA 时区数据库（又叫 tzdata）是维护全球时区定义的标准数据库，里面记录了每个地区的历史时区变化、夏令时规则以及相关法律变动。使用Asia/Shanghai这样的标识，意味着你引用的是一整套完整规则，而不只是一个静态偏移量。
举几个实际例子：
America/New_York在不同季节会自动对应 UTC-5 和 UTC-4，你用这个标识让Intl.DateTimeFormat去格式化时间，它会自动处理夏令时。Europe/Berlin也一样，3 月最后一个周日切换到夏令时，10 月最后一个周日切回来，这些规则全部由 tzdata 内置，不需要你手写判断。- 有些地区历史上改变过时区规则，比如某个国家因为政治或经济原因调整了时区偏移，IANA 数据会完整记录下来。用偏移量去标记历史时间点会彻底错乱，用 IANA 标识就能正确定位当时当地的真实时间。
所以当我的项目需要把“用户时区”存到数据库时，我一律存储 IANA 时区标识符，而不是数字偏移量。后端在做时间转换时，直接消费这个标识符，交给 dayjs、date-fns-tz 这类库去处理，非常省心。
3. 浏览器兼容性差异：哪些环境下会翻车
理论讲完了，回到实战。Intl.DateTimeFormat().resolvedOptions().timeZone这个 API 虽好，但不同浏览器表现并不完全一致，尤其某些老内核和特殊 WebView 环境下容易翻车。我把自己在项目中实测的结果整理了一下。
3.1 兼容性矩阵：主流浏览器现状
| 浏览器 | 最低版本支持 | 是否返回 IANA 时区名 | 备注 |
|---|---|---|---|
| Chrome | 24+ | 是 | 最稳，现代版本无问题 |
| Firefox | 52+ | 是 | 较老版本存在跨年 bug，现代版本正常 |
| Safari | 10.1+ | 是 | iOS 上也正常 |
| Edge（Chromium 内核） | 79+ | 是 | 现代 Edge 完全兼容 Chromium 行为 |
| Edge（EdgeHTML 老内核） | 18 及以下 | 通常是 | 偶有返回 UTC 的 bug，不推荐依赖 |
| IE 11 | 11 | 否 | resolvedOptions()不提供timeZone字段，返回 undefined |
| 部分 Android WebView | 不定 | 视系统而定 | 旧系统上可能缺失 ICU 数据导致行为异常 |
这里面最值得注意的是 IE 11。Intl.DateTimeFormat在 IE 11 里是存在的，但它的resolvedOptions()结果里没有timeZone字段，你访问就是undefined。如果客户环境还停留在 IE 系浏览器，必须做降级。
至于部分老 Android WebView 返回异常，本质是缺少完整的 ICU（International Components for Unicode，Unicode 国际化组件）数据。没有 ICU 数据，就算浏览器引擎支持这个 API，也没法正确映射操作系统时区到 IANA 标识。
3.2 踩过的坑：时区识别结果不一致与降级策略
我第一次遇到这个问题是在一个混合 App 项目里。iOS 端的 WKWebView 表现完美，返回Asia/Shanghai，但同一套代码在安卓端一台很旧的三星手机上跑，居然返回了undefined。排查了很久发现是那台手机的系统 WebView 版本太老，ICU 数据缺失，resolvedOptions()里压根没有timeZone字段。
所以我现在写通用的时区获取工具函数，一定会带降级逻辑：
function detectTimeZone() { try { const timeZone = Intl.DateTimeFormat().resolvedOptions().timeZone; if (timeZone && typeof timeZone === 'string' && timeZone.length > 0) { return timeZone; } } catch (e) { // 忽略错误，走降级 } // 降级方案一：用 getTimezoneOffset 估算，并猜测常见时区 const offset = new Date().getTimezoneOffset(); return guessTimeZoneByOffset(offset); }降级的核心思路是“能拿到名就用名，拿不到名就退而求其次用偏移量”。guessTimeZoneByOffset可以根据偏移量映射到常见时区，但要记住这种猜测是不精确的——比如偏移量为 -480 时，可能对应中国标准时间、马来西亚时间、新加坡时间，只能返回一个默认值。
另一个坑是：同一个浏览器，用户改了操作系统时区后，API 返回值会随之变化。这不是浏览器 bug，而是设计如此。如果你需要的是“用户注册所在地”的时区，建议在注册或首次访问时就把时区名保存到用户资料里，而不是每次都实时获取。否则就会出现用户出差到美国，你看他的时区变来变去，统计数据直接乱掉。
4. 获取浏览器支持的完整时区列表：两种可行方案
项目做到中期，产品提了个需求：用户设置页里要有一个时区下拉选择框，列出所有可用时区供用户手动覆盖默认值。这就需要“浏览器支持的完整时区列表”。这个需求比想象中麻烦一些，因为浏览器并没有提供一个 API 直接返回所有时区名，至少以前没有，现在有了。
4.1 Intl.supportedValuesOf：现代浏览器的新钥匙
Intl.supportedValuesOf()是 ECMAScript Intl 规范新增的 API，专门返回运行环境支持的某种数值列表。传入'timeZone'就能拿到完整的 IANA 时区标识数组：
const zones = Intl.supportedValuesOf('timeZone'); console.log(zones); // 输出类似： // ["Africa/Abidjan", "Africa/Accra", "Africa/Addis_Ababa", ...]这个 API 的支持情况：
| 浏览器 | 支持版本 |
|---|---|
| Chrome | 99+ |
| Edge | 99+ |
| Firefox | 93+ |
| Safari | 15.4+ |
我测试下来，返回的列表包括了大约 400 个左右的时区标识，都是标准 tzdata 的子集。用这个列表渲染下拉框非常干净，不需要自己维护数据。
不过要注意：Intl.supportedValuesOf不是所有项目都能用的。老项目如果还要兼容 Firefox 92 以下或者 Safari 15.3 以下，就得用降级方案。
4.2 枚举探测方案：兼容老环境的笨办法
在没有Intl.supportedValuesOf的情况下，可以预先准备一份时区标识列表，然后逐个用Intl.DateTimeFormat格式化同一个日期去探测，能正常解析的说明浏览器支持，不能解析的就会被RangeError拦住。实现如下：
const TIME_ZONES = [ 'Asia/Shanghai', 'Asia/Tokyo', 'Asia/Hong_Kong', 'Asia/Singapore', 'America/New_York', 'America/Los_Angeles', 'America/Chicago', 'America/Denver', 'Europe/London', 'Europe/Paris', 'Europe/Berlin', 'UTC', // 这里可以维护一份完整的 IANA 时区列表，通常几百个 ]; function getSupportedTimeZones() { if (typeof Intl.supportedValuesOf === 'function') { return Intl.supportedValuesOf('timeZone'); } const probeDate = new Date(2020, 0, 1, 12, 0, 0); return TIME_ZONES.filter(function (zone) { try { const formatter = new Intl.DateTimeFormat('en-US', { timeZone: zone, hour12: false }); const result = formatter.format(probeDate); return result.indexOf('Invalid') === -1; } catch (e) { return false; } }); }这段代码的关键点是：
probeDate选一个固定的日期时间，不要用new Date()，因为不同时区在不同季节的夏令时状态不同，固定日期能保证格式化结果可比。- 用
try...catch捕获RangeError，这是Intl系列 API 在不支持指定时区时的标准行为。 - 格式化结果的字符串如果包含
Invalid，说明解析失败，需要过滤掉。
枚举方案的缺点是时区列表需要自己维护。我建议把 IANA 标准列表一劳永逸地存放在一个 JSON 文件里，构建时打包进去，运行时只要做过滤就行。这样不依赖Intl.supportedValuesOf也能拿到全量列表。
5. 项目实战中的几个高频问题与处理经验
光把时区名读出来还不够，实际项目里围绕“时区”这个主题还有很多配套问题。这些都是在真实交付中踩出来的经验，随手分享一下。
5.1 时间戳、日期格式化和时区三者要分开处理
这里容易犯的一个错误是：把“存储时区标识”和“格式化展示”混为一谈。
我推荐的做法是：
- 存储层：一律使用时间戳（epoch millis）或带时区信息的 ISO 字符串（如
2025-06-01T09:30:00+08:00），不要存“年-月-日 时:分:秒”这种裸字符串。 - 展示层：用用户时区标识符去格式化。后端 API 返回时间戳，前端拿到后用
Intl.DateTimeFormat配合用户时区标识格式化。 - 计算层：时间运算统一用 UTC 时间戳操作，避免在本地时间字符串上做加减。
最佳实践中，我会把用户时区标识作为一条独立字段后端存储，一旦确定就不希望它频繁变动。配合Intl.DateTimeFormat的timeZone选项来格式化每一次展示，效果是最稳的。
来看一段完整的格式化示例：
const userTimeZone = 'Asia/Shanghai'; const formatter = new Intl.DateTimeFormat('zh-CN', { timeZone: userTimeZone, year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }); const timestamp = Date.now(); console.log(formatter.format(new Date(timestamp)));如果你想在项目里统一封装，可以做一个时区工具模块，把detectTimeZone、formatInTimeZone、getSupportedTimeZones全部收拢到一个文件里，测试起来也方便。
5.2 检测用户时区变化的可行性
有一种场景：用户开着网页，系统时区从Asia/Shanghai改成了America/New_York。页面上的时间显示要不要实时跟着变？
从技术上讲，可以监听visibilitychange事件和定时器轮询：
let lastTimeZone = detectTimeZone(); function monitorTimeZoneChange(callback) { function check() { const current = detectTimeZone(); if (current !== lastTimeZone) { lastTimeZone = current; callback(current); } } document.addEventListener('visibilitychange', check); setInterval(check, 60000); }实测下来，visibilitychange是最可靠的触发点，因为用户改完系统时区后往往会切回浏览器页面。定时器是兜底方案，但间隔不要设置太短，一分钟一次足够了，不然浪费资源。
需要警惕的是：这个监听不能完全依赖。有些浏览器在系统时区变化后不会立即更新Intl.DateTimeFormat().resolvedOptions()的结果，可能需要刷新页面才能拿到新值。所以这个功能定位为“尽力而为”，不要把它当成强一致性的同步机制。
5.3 时区名展示的本地化问题
当你把时区列表渲染成下拉框时，会发现Asia/Shanghai这种英文标识直接展示给用户非常不友好。国际用户看到Asia/Shanghai还好，中国用户看到Asia/Urumqi可能完全不知道那是什么地方。这里可以做一层本地化映射。
简单做法是为常见时区维护一个本地化名称表。如果需要自动化处理，可以使用Intl.DateTimeFormat加timeZoneName选项去生成展示名：
function getTimeZoneDisplayName(timeZone, locale = 'zh-CN') { try { const formatter = new Intl.DateTimeFormat(locale, { timeZone: timeZone, timeZoneName: 'long' }); // 用 0 点作为参照点，只取 timeZoneName 部分 const parts = formatter.formatToParts(new Date(0)); const namePart = parts.find(part => part.type === 'timeZoneName'); return namePart ? namePart.value : timeZone; } catch (e) { return timeZone; } } console.log(getTimeZoneDisplayName('Asia/Shanghai', 'zh-CN')); // 输出类似：中国标准时间这样至少能让用户明白选项指的是什么。不过注意，formatToParts里timeZoneName的本地化文案在不同浏览器上有细微差异，可用作展示，不建议用于比较或传参。
还有一个容易被忽略的细节：用户手动选择了时区后，别把用户选择结果覆盖掉。可以用 cookie 或 localStorage 保存用户手动选择，每次打开页面时先读取用户选择，没有再走系统检测逻辑。这能有效避免用户出差后系统时区变化导致界面时间突然“变了”的困惑。
从最开始踩的服务器时区坑，到后来用Intl系列 API 把用户时区识别、时区列表、格式化展示全部打通，这套方案到目前为止运行稳定，交付给客户的几个国际化项目都没有再出过时间错乱的投诉。如果你也在做类似功能，建议直接参考上面的工具函数，至少能省掉我当初摸索的那几个通宵。
