世界时区与时间会议：跨国协作时间换算

GMT（格林威治平均时）是基于地球自转的太阳时标准，由英国皇家格林威治天文台在 19 世纪末建立。它观测太阳在本地子午线的视圆周运动，定义「正午」的时刻。GMT 在民用时间中用了 100+ 年。

UTC（协调世界时）是现代原子钟基础的时间标准，由国际电信联盟在 1960 年代定义。UTC 基于原子秒（定义为铯-133 原子特定跃迁的周期），精确度达纳秒级。为了让 UTC 不与地球自转的太阳时相差超过 0.9 秒，国际地球自转服务每隔几年会在 UTC 中插入或删除一个「闰秒」。

实用差异：

• 民用场景（日常说话、简单应用）：GMT 和 UTC 基本等价，差别小于 1 秒，可互换使用。
• 科学与卫星应用（GPS、天文、精密测量）：必须用 UTC，因为闰秒的累积会导致导航错误。
• 编程时：永远用 UTC（或「Z」时区标记），再在客户端转换为本地时区显示。

总结：GMT 是太阳时标准，UTC 是原子时标准；通俗说话可混用，严格编程要用 UTC。

世界各地的时区和夏令时规则管理权属于各国政府，导致「标准」并不统一。IANA（互联网号码分配权威）维护的时区数据库是全球公认的权威参考。

每个时区在 IANA 数据库中用 大陆/城市 格式表示，如 Asia/Shanghai、Europe/London、America/New_York。每个时区条目记录：

• 相对 UTC 的基准偏移（如 UTC+8）
• 历史上的所有偏移变更
• 夏令时的生效和结束日期（精确到年月日时分秒）
• 特殊名称（如 CST 可能是中国标准时或中央标准时，歧义很大）

例子说明问题的复杂性：

• 中国：全国统一使用 UTC+8（北京时间），无夏令时。简单。
• 美国：有 4 个不同的时区（东部、中部、山地、太平洋），各自在 3 月第二个周日和 11 月第一个周日切换夏令时，但印第安纳州等有例外。极复杂。
• 欧盟：统一在最后一个周日 3 月切换到夏令时（UTC+1 变 UTC+2），10 月切换回标准时间。

这就是为什么 JavaScript 库（如 moment-timezone、dayjs）和操作系统都必须嵌入 IANA 数据库，并定期更新以应对政府的规则变更。

夏令时（Daylight Saving Time, DST）是为了「充分利用日光」而将时钟拨快 1 小时的做法，通常在春季执行，秋季回拨。但并非所有国家都使用。

采用夏令时的地区： - 北美：大部分美国和加拿大（除亚利桑那州、夏威夷） - 欧盟：所有成员国（但每年讨论是否取消） - 一些中东和南方国家：规则各异

不采用夏令时的地区： - 中国、日本、韩国 - 大部分非洲、亚洲国家 - 新西兰和澳大利亚的部分州

跨国协作中的陷阱：

• 时间偏移突变：美国 3 月切换时，与中国的时差从 12 小时变 13 小时。会议时间必须重新算。
• 重复时刻：秋季切换回标准时间时，会有一小时「重复」两次（例如 1:30 AM 出现两次）。数据库插入、日志时间戳容易出错。
• 缺失时刻：春季切换为夏令时时，会跳过某小时（如从 1:59:59 AM 直接跳到 3:00:00 AM）。

编程最佳实践：

1. 所有时间戳都用 UTC 存储。
2. 显示给用户时再转换为其本地时区。
3. 用成熟的时间库（Intl.DateTimeFormat、moment-timezone、dayjs）处理转换，不要手工计算。
4. 跨时区的定时任务用 UTC 触发时间。

浏览器内置的 Date 对象有严重的时区支持缺陷——它知道当前本地时区，但无法处理任意时区的格式化与转换。这是为什么时间库必需。

Intl.DateTimeFormat（原生 API） `` const date = new Date(); const formatter = new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai', year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit' }); console.log(formatter.format(date)); `` 现代浏览器都支持，无需额外库，但 API 繁琐。

moment-timezone（传统但体积大） `` moment.tz("2026-04-29 15:30", "YYYY-MM-DD HH:mm", "Asia/Shanghai").tz("America/New_York").format(); `` 功能全面，但打包后 > 60KB，不适合轻量级项目。

dayjs + plugin（现代轻量） `` dayjs("2026-04-29 15:30").tz.setDefault("Asia/Shanghai").tz("America/New_York").format(); `` 核心仅 2KB，插件按需加载，推荐新项目。

选择建议：

• 简单查询：用 Intl.DateTimeFormat
• 复杂计算：用 dayjs + timezone 插件
• 遗留项目迁移：先用 moment-timezone，逐步迁移到 dayjs

如何在分布式团队中优雅地安排会议？实践出的金律是：

金律 1：总是用 UTC 时间发送会议邀请 例：「会议时间：2026-04-29T14:00:00Z」（末尾的 Z 表示 UTC）。每个人的日历客户端（Outlook、Google Calendar、Apple Calendar）都会自动转换为当地时间显示。

金律 2：在会议通知中同时列出主要参与者的本地时间 例： `` 2026-04-29 14:00 UTC = 2026-04-29 22:00 中国（UTC+8） = 2026-04-29 10:00 纽约（UTC-4，夏令时） = 2026-04-29 15:00 伦敦（UTC+1，夏令时） `` 这样每个人一眼看到自己的时间，不用心算。

金律 3：夏令时切换前提醒重新确认 DST 切换后时差变化，用日历客户端自动管理这一点：用 UTC 创建的日历项目会自动调整，但心理上人们容易弄错。提前一周重申。

工具链推荐：

• 日历：Google Calendar 或 Outlook，都内置时区自动转换。
• 站会通知：用本站的世界时钟工具快速生成参与者们的本地时间表，复制粘贴到 Slack。
• 会议软件：Zoom、Teams、Slack Huddle 都会显示参与者的本地时间，无需额外配置。

许多 Web 应用想要自动检测用户的时区，避免让用户手动选择。一个常见的方法是根据 IP 地址推断时区。

原理：通过 GeoIP 数据库（MaxMind、IP2Location 等）把 IP 地址映射到地理位置，再根据地理位置查表得到时区。例如 IP 来自纽约，推断时区是 America/New_York。

准确度问题：

• VPN 和代理：用户可能用 VPN 连接，IP 来自美国但人在中国，推断完全错误。
• 企业网络：大公司的所有员工可能共享一个 IP，地理位置映射到公司所在地，而员工身在全球各地。
• 移动用户：移动设备会改变 IP（切换 WiFi 或 4G），时区推断可能频繁闪烁。
• GeoIP 数据过时：地理位置数据库更新延迟，某些 IP 的映射可能相差数百里。

实践建议：

1. 首次访问：可用 IP 推断作为默认值，但不强制。
2. 让用户选择：提供时区选择器（下拉菜单），让用户手动确认或修改。
3. 记住选择：用 localStorage 或账户设置保存用户的时区偏好，后续访问使用保存值。
4. 检测系统时区：优先使用 JavaScript 的 Intl.DateTimeFormat().resolvedOptions().timeZone 获取操作系统的时区，这比 IP 推断准确得多。

总结：自动检测很便利，但为了避免出错，最好还是让用户确认一次。