“时区Timezone一览表”——这个标题乍一看像是个简单工具但它背后牵扯的东西远比表面多。无论你是跑服务器的后端开发、管全球团队的项目经理、做跨境业务的运营还是只是经常出差、远程开会、跟海外朋友联机打游戏时区问题总会以各种姿势找上门。我这些年踩过的坑从服务器时间错乱导致凌晨疯狂告警到会议通知把老外约到半夜再到电脑不知怎么的时区注册表损坏导致系统时间怎么改都不对攒了一肚子经验干脆整理成一份既有一览表、又有实操排查的完整笔记。1. 时区基础原理与核心概念1.1 时区到底是什么为什么不能全世界统一时间很多人会问一个很自然的问题既然网络是全球互联的为什么不能全世界都用同一个时间非要搞出这么多时区答案是时区本质上不是技术需求而是人类生活作息的映射。地球自转一圈是24小时不同经度的地方看到太阳的时间不同。正午时分太阳在头顶但要是整个地球都用同一个时间那东边的人下午三点天还没亮西边的人半夜十二点阳光刺眼生活节奏全乱。所以才有了本初子午线0度经线通过英国格林尼治作为基准向东向西每隔15度经度划分一个时区理论上一共24个时区。不过实际的时区划分远远没这么“规矩”。国家边界、历史原因、政治决策都会打断理论上的经度线。比如中国虽然横跨五个理论时区但全国统一使用北京时间东八区尼泊尔用了UTC5:45这种带45分钟偏移的奇葩时区甚至有些国家因为领土跨度过大一国之内就好几个时区。这些“不整齐”恰恰是软件系统里时区处理最容易出bug的地方。这里必须引入一个核心概念UTC协调世界时。你可以把它理解成“世界的绝对时间”它不受任何地区法律、夏令时影响是一个恒定不变的标尺。所有时区都是相对于UTC的偏移量比如UTC8就是比UTC快8小时UTC-5就是比UTC慢5小时。我们日常说的“北京时间”其实就是UTC8而“格林尼治标准时间GMT”经常和UTC混用严格来说GMT是一种时间标准UTC是更精确的原子钟标准但在绝大多数应用场景下二者可以视为同一基准。1.2 偏移量、UTC与时间戳的区别很多刚接触时区的人会混淆三个概念偏移量、UTC时间、时间戳。我举一个具体例子说明。假设现在是UTC时间2025年1月15日 12:00:00北京时间 UTC8 2025年1月15日 20:00:00纽约时间冬令时UTC-5 2025年1月15日 07:00:00悉尼时间夏令时UTC11 2025年1月15日 23:00:00而**时间戳Timestamp**又是另一回事。它是从1970年1月1日00:00:00 UTC到现在的总秒数或毫秒数。注意它的基准是UTC所以无论你在哪个时区同一时刻的Unix时间戳是绝对一致的。这就是为什么服务器存储时间时最佳实践永远是存时间戳或UTC时间而不是存“2025-01-15 20:00:00”这种带时区含义的本地时间。你可以把时间戳想象成绝对坐标把UTC想象成中性标尺把各时区时间想象成不同语言对同一个时刻的描述。一个时刻只有一个绝对坐标但可以被描述成无数种“本地语言”。系统设计中如果存了本地时间而没有记录时区信息等于只记了“北京说法”而没存“绝对坐标”一旦换环境解读就容易出错。2. 全球时区一览表与命名规则解析2.1 常用标准时区对照表日常开发和协作中用不到全部四十多个时区大部分场景只涉及下面这些主要时区。我把它们整理成一张快速参考表按UTC偏移量排列UTC偏移量中文名称英文/IANA名称代表城市/地区备注UTC14莱恩群岛时间Pacific/Kiritimati基里巴斯莱恩群岛全球最早进入新的一天UTC13新西兰夏令时Pacific/Auckland惠灵顿、奥克兰新西兰夏令时期间UTC12新西兰标准时间Pacific/Auckland惠灵顿、奥克兰冬令时同时有斐济、堪察加等UTC11澳大利亚东部夏令时Australia/Sydney悉尼、墨尔本澳大利亚夏令时期间UTC10澳大利亚东部标准时间Australia/Sydney悉尼、墨尔本冬令时还有海参崴等UTC9日本标准时间Asia/Tokyo东京、首尔、雅加达日韩朝统一用此偏移UTC8中国标准时间Asia/Shanghai北京、上海、新加坡、马尼拉整个东八区包括港澳台UTC7中南半岛时间Asia/Bangkok曼谷、雅加达、河内泰国、越南、印尼部分UTC6:30缅甸时间Asia/Yangon仰光半小时偏移常见地区之一UTC5:45尼泊尔时间Asia/Kathmandu加德满都少见的45分钟偏移UTC5巴基斯坦标准时间Asia/Karachi卡拉奇、伊斯兰堡同时有孟买UTC5:30UTC4海湾标准时间Asia/Dubai迪拜、阿布扎比同时有莫斯科夏令时等UTC3莫斯科标准时间Europe/Moscow莫斯科、内罗毕、巴格达非洲东部也常用UTC2东欧时间Europe/Kyiv开罗、雅典、赫尔辛基夏季东欧夏令时也是UTC3UTC1中欧时间Europe/Berlin柏林、巴黎、罗马、马德里西欧大部分国家冬令时UTC0格林尼治标准时间Europe/London伦敦、里斯本、阿克拉英国冬令时夏令时变UTC1UTC-1亚速尔时间Atlantic/Azores亚速尔群岛葡萄牙海外领地UTC-2费尔南多时间America/Noronha巴西费尔南多群岛少用UTC-3巴西利亚时间America/Sao_Paulo圣保罗、布宜诺斯艾利斯南美大部UTC-4大西洋标准时间America/Halifax加拉加斯、圣胡安加拿大大西洋省UTC-5东部标准时间America/New_York纽约、华盛顿、多伦多美国东部冬令时UTC-6中部标准时间America/Chicago芝加哥、墨西哥城美国中部冬令时UTC-7山区标准时间America/Denver丹佛、菲尼克斯州内部分不实行夏令时亚利桑那州大多数地区不启用夏令时UTC-8太平洋标准时间America/Los_Angeles洛杉矶、温哥华、西雅图美国西海岸冬令时UTC-9阿拉斯加标准时间America/Anchorage阿拉斯加州大部分加上阿留申群岛部分区域为UTC-10UTC-10夏威夷标准时间Pacific/Honolulu檀香山夏威夷不实行夏令时UTC-11萨摩亚标准时间Pacific/Pago_Pago帕果帕果美属萨摩亚UTC-12贝克岛时间Etc/GMT12无人岛实际几乎无人使用这张表最大的作用是快速换算。比如你要跟洛杉矶的客户约时间现在是北京时间的上午10点洛杉矶处于冬令时UTC-8那么 北京时间UTC8到洛杉矶UTC-8相差16小时洛杉矶时间 10:00 - 16:00 前一天18:00。如果是夏令时期间UTC-7那就相差15个小时。2.2 Windows、Linux和IANA时区命名的差异这是很多人容易踩坑的地方Windows和Linux/Unix系统的时区命名体系完全不一样。Windows用的是一套“人类友好”的名称比如“China Standard Time”“Pacific Standard Time”“Eastern Standard Time”这些名称来自操作系统内的时区注册表键。而Linux、macOS、Java、Python的dateutil、Node.js等大量现代软件平台使用的是IANA时区数据库完整名称是“Area/Location”格式比如Asia/Shanghai、America/New_York、Europe/London。为什么不用Windows那套因为Windows名称存在两个严重问题一是夏令时规则颗粒度太粗同叫“Eastern Standard Time”的纽约和多伦多可能切换日的规则不同二是它不区分“城市”只区分“规则”一旦某地立法改了时区规则Windows名称对应的规则可能没跟上。IANA数据库则每半年更新一次历史时区变化都有记录软件开发者社区公认的标准就是它。所以当你配置服务器时如果用了Windows服务器可以在控制面板里选“中国标准时间”这是Windows的命名。而Linux服务器上你要设置的是“Asia/Shanghai”不是“UTC8”。很多新手在Linux上直接写“UTC8”会被系统拒绝因为Linux能识别的就是IANA名称。建议所有新写的代码、新部署的服务器一律以IANA时区名为准。甚至在Windows环境下也尽量在应用层使用IANA名称通过转换库做映射Windows系统只负责最底层的时间计算。3. 服务器时区配置实战3.1 Linux服务器时区设置方法服务器时区配错最典型的后果是定时任务cron半夜触发、日志时间错乱、跟客户端时间对不上导致接口签名验证失败。我自己就遇到过日志时间全差8个小时排查了半天才发现是容器镜像默认时区是UTC。Linux服务器设置时区最推荐的方式是使用timedatectl命令这在几乎所有现代systemd系统上都可用。# 查看当前时区状态 timedatectl # 列出所有可用时区 timedatectl list-timezones # 设置时区为上海中国标准时间 sudo timedatectl set-timezone Asia/Shanghai # 确认结果 timedatectl如果没有timedatectl老系统、精简容器另一种方式是直接软链文件# 备份原时区文件 sudo cp /etc/localtime /etc/localtime.bak # 设置时区为上海 sudo ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime # 验证 date这里的关键点在于/etc/localtime是一个指向/usr/share/zoneinfo/下具体时区文件的软链接。系统读取本地时间时就是通过这个链接解析对应时区规则。直接复制文件而不是建软链也能用但不利于后续通过update机制更新时区数据库所以建软链更优。还有一个容易忽略的是硬件时钟RTC的问题。服务器有硬件时钟和系统时钟两套时间硬件时钟使用UTC还是一个不知名的本地时间取决于/etc/adjtime文件的状态。对于只跑业务应用的云服务器建议硬件时钟统一用UTC系统内的时区只影响展示和解释这样能避免双时钟互相干扰。# 设置硬件时钟使用UTC sudo timedatectl set-local-rtc 03.2 Docker容器与Java/Python/Node.js的时区问题容器化部署之后时区问题会变得更加隐蔽。Docker基础镜像如alpine、ubuntu官方镜像默认都是UTC时区如果你在容器里跑业务代码而不同步宿主机时区就会出现容器内日志时间比宿主机差8小时的情况。Docker容器同步宿主机时区的三种常用方法方法一启动时挂载宿主机时区文件docker run -v /etc/timezone:/etc/timezone:ro -v /etc/localtime:/etc/localtime:ro your_image注意不同镜像需要挂载的文件不同。Debian系有/etc/timezone而Alpine没有这个文件需要额外处理。方法二在Dockerfile中安装tzdata并设置时区FROM alpine:3.19 RUN apk add --no-cache tzdata \ cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ echo Asia/Shanghai /etc/timezone方法三通过环境变量TZ设置时区docker run -e TZAsia/Shanghai your_image第三种方法对Java某些版本、Python的zoneinfo、Node.js的date库都有效但如果你用C/C的底层gmtime/localtime函数TZ环境变量也能影响到。建议三种结合使用保证万无一失。编程语言层面也要注意JVM启动时如果没有指定时区会读取操作系统默认值。生产环境最好在JVM启动参数里强制指定java -Duser.timezoneAsia/Shanghai -jar your_app.jarPython的datetime.now()默认返回本地时区看似方便但实际上它依赖操作系统时区配置。更好的做法是使用zoneinfo模块显式指定from datetime import datetime from zoneinfo import ZoneInfo # 显式获取上海时区时间不依赖系统环境 now_shanghai datetime.now(ZoneInfo(Asia/Shanghai)) print(now_shanghai)Node.js中推荐使用Luxon或date-fns-tz处理时区光靠原生Date对象处理不同时区很容易写出“午夜翻车”的代码。3.3 Windows服务器时区配置Windows服务器的时区配置通常通过控制面板或PowerShell完成。特别要注意的是Windows服务器的“时区”设置会直接影响IIS日志时间、计划任务时间、以及其他依赖本地时间的系统组件。# 查看当前时区 Get-TimeZone # 设置时区为中国标准时间 Set-TimeZone -Id China Standard Time # 列出所有可用时区ID Get-TimeZone -ListAvailableWindows的时区ID和IANA名称不同例如中国的Windows时区ID是“China Standard Time”对应的IANA名称是“Asia/Shanghai”。如果业务代码里写死了Windows时区ID迁移到Linux时就要注意转换。4. 电脑无法识别时区注册表排查与修复4.1 症状分析时区怎么突然“失灵”了排查“电脑无法识别时区注册”之前先说清楚它的典型症状。这类问题常见于Windows系统表现形式多种多样系统设置的时间与日期里时区下拉框是空的或者选项列表里只有一个奇怪的默认值。你手动改了时区点击“确定”后过几秒又跳回原来的UTC或北京时区。Windows日志或第三方安全软件报错提示“时区注册表读取失败”或“timezone registry key missing”。任务计划程序、Windows时间服务W32Time出现异常某些软件显示的时间跟实际时间差几个小时。如果你遇到这些现象大概率是注册表中的时区信息出现了问题。Windows的时区信息存储在注册表路径下HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones这个键下面记录了系统支持的所有时区列表每个时区以子键形式存在比如“China Standard Time”“Pacific Standard Time”等里面包含时区显示名、标准名称、夏令时规则、偏移量等数据。系统设置界面读取的就是这里的数据。如果这个键被损坏、部分子键丢失或权限异常就会出现“系统无法识别时区”的故障。先说一个常见误区很多人一看到“时区注册表”就以为它是唯一的时区信息来源。实际上Windows还有另外两个地方存储当前生效的时区设置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation这个路径存储的是当前系统正在使用的时区信息包括TZITIME_ZONE_INFORMATION结构、动态夏令时规则等。它和Time Zones键一个管列表、一个管当前状态。两者一起出问题时才叫“电脑无法识别时区”。4.2 修复步骤注册表损坏后的恢复流程遇到这类问题按以下顺序排查和修复。第一步先确认注册表键是否存在。按下WinR输入regedit进入注册表编辑器定位到计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones看看里面有没有至少几十个子键。如果这个路径不存在或者只有个别子键说明时区数据表丢失。第二步尝试通过系统内置方法修复。在“设置-时间和语言-日期和时间”里先关闭“自动设置时区”开关然后选一个其他时区应用后再选回你需要的时区。有时候这个操作会让系统重新写入有效的注册表数据。第三步如果第二步没有效果可以用管理员的命令提示符执行以下命令# 停止Windows时间服务 net stop w32time # 重新注册Windows时间服务的DLL regsvr32.exe /i w32time.dll # 重新启动Windows时间服务 net start w32time但很多时候DLL注册能修复服务本身对注册表键缺失的帮助有限。第四步恢复完整的时区注册表键。最简单可靠的方式是从一台正常工作的同版本Windows电脑导出整个Time Zones键然后导入到故障机器上。导出方法在正常电脑上打开regedit定位到上述Time Zones路径右键点击“Time Zones”目录选择“导出”保存为.reg文件拷贝到故障电脑双击导入或者用命令导入reg import timezones.reg导入后重启电脑再到“设置”里重新设置时区大概率就好。第五步不要让时区问题牵扯到系统更改。如果以上流程都无效使用系统还原到之前正常的还原点或者用“启用或关闭Windows功能”里的“时区”组件重新安装。但一般情况下前四步已经能覆盖绝大多数场景。4.3 预防注册表时区问题的操作习惯说白了“电脑无法识别时区注册”这类故障大多数是三个原因一是使用“优化大师”“系统清理工具”误删了注册表键二是杀毒软件误报并隔离了相关注册表项三是手动编辑注册表时写错了键值。我自己处理这种故障时的一个心得是千万别用各种“一键优化”工具去清理注册表尤其是涉及Time Zones这种系统级数据清理工具判断不出哪些是冗余项。系统的时区信息量很小撑死几十KB没有任何清理价值反而容易误伤。另外如果公司电脑是域环境时区设置还可能被组策略控制。域管理员可以通过组策略强制指定时区导致本机手动修改无效。这种情况不是注册表损坏而是策略限制需要检查计算机配置\管理模板\Windows 组件\终端服务\TS 授权\限制每个用户一个终端服务会话不对更准确的说时区策略在组策略里叫“设置时区”计算机配置\管理模板\Windows 组件\时间和日期\设置时区如果这个策略已启用本机用户无法修改时区。这时需要域管理员调整策略或者在命令提示符下检查gpresult /r查看是否有相关策略生效。5. 常见时区问题与排查技巧实录5.1 服务器时间老是差8小时问题出在哪这是最最常见的问题没有之一。服务器时间差8小时90%的情况是服务器硬件时钟用的是本地时间而系统装载镜像时默认把/etc/localtime设置成了UTC或者反过来。解决方法前面已经写过用timedatectl或软链统一设置就好了。但还有一种隐蔽情况数据库连接串里写了时区参数导致应用读到的时间被DB转换了一次。以MySQL为例如果连接参数里写了“serverTimezoneUTC”而数据库实际存储用的是CST中国标准时间那读到的时间就会差8小时。排查这类问题先看数据库和应用的时区是否一致再统一到同一条时间链路。5.2 夏令时带来的“幽灵时间”与重复时间夏令时是个长期困扰开发者的东西。实行夏令时的地区在春季切换日会“跳过”一小时比如美国东部时间从凌晨2点直接跳到3点那么2:00到2:59这一小时在当天不存在秋季切换日则会“重复”一小时凌晨1点重复两遍。这种规则对定时任务、循环判断、订单超时计算非常不友好。我建议的应对策略如果业务不涉及北美、欧洲、澳洲等夏令时地区优先全部以UTC计算只在展示层转换为本地时区。如果业务涉及夏令时地区不要自己写夏令时切换逻辑直接用IANA时区数据库它内置了完整的夏令时生效历史和规则。定时任务如果要“同时触发”用CMSCron表示法表达时最好用UTC的cron表达式而不是每个地区本地时间的cron表达式。因为一旦夏令时切换某一天的cron可能会触发两次或零次而基于UTC的表达式稳定且可预测。5.3 网页、手机App和邮件附件的时区显示不一致我见过一个真实案例用户在网页上看到活动时间是晚上8点但收到的邮件附件日历里是早上8点差12小时还多。原因就是邮件里的iCalendar.ics附件的时区定义用了UTC TIME而日历客户端默认解析成了本地时区没有做正确的时区偏移转换。解决这一类问题的通用原则是存储层数据库存储时间一律用UTC时间戳或Java Instant / Python aware datetime不要存无时区信息的字符串。传输层API接口传时间统一用ISO 8601格式并且带时区偏移比如2025-01-15T20:00:0008:00不要裸传2025-01-15 20:00:00。展示层前端拿到时间戳后用用户所处的本地时区渲染浏览器可以通过Intl.DateTimeFormat().resolvedOptions().timeZone拿到用户时区。5.4 时区查询与换算的实用工具我日常用的工具不多但都经过验证省时省力Linux/Unix终端直接用date和tzselect配合前面说的timedatectl足够了。跨时区会议安排我一般用worldtimebuddy.com这类在线网页拖拽时区列表一眼看到重叠时间。写代码时处理时区首选Python的zoneinfoPython 3.9内置、Node.js的Luxon、Java 8的java.time.ZoneId全是基于IANA数据库。数据库层面PostgreSQL的TIMESTAMPTZ比MySQL的DATETIME更适合存跨时区时间。TIMESTAMPTZ内部存UTC展示时按会话时区转换很多隐性bug都因此避免。6. 提高效率的时区处理习惯6.1 给团队定一套“时区规范”如果你带团队或者维护一个仓库强烈建议在项目文档里写明时区约定。我建议的默认约定是所有后端接口、数据库、日志一律UTC。日志里附带时区信息例如用ISO 8601格式带上UTC偏移。前端展示本地化。配置文件里的“本地时间”只允许出现在部署环境变量中不允许硬编码。这套约定执行下来团队内很少会因为时间问题扯皮。跨时区协作的群聊里尽量在消息里标注时间和时区例如“周四20:00北京时间UTC8”避免大家自行脑补。6.2 设计可靠的全天候监控与提醒对于需要7x24小时响应的业务时区处理尤其关键。比如我们有一个全球监控系统报警消息里如果只显示服务器本地时间那在跨时区排班时就会造成“到底几点出问题”的困惑。改进方式是把告警时间统一换算为值班人员的本地时区或者直接在消息中同时显示UTC时间和目标时区时间减少人工换算。还有一个容易忽略的细节日志rotate时间。如果日志文件按天切割但服务器时区设错了日志文件名里的日期就会和实际时间对不上尤其是每天00:00场景。检查时务必确认日志轮转基于正确的本地时区。6.3 结合业务场景选择“友好”时区最后说一个偏产品和业务层面的经验面向用户的系统最好让用户自己选择时区而不是傻乎乎地猜测用户位置。很多用户出差、跨国旅行时设备时区会自动切换系统如果不支持手动指定时区就会在他的日历和订单记录里造成混乱。业务系统中至少要支持“跟随系统时区”和“手动指定时区”两种模式。尤其是在预订、会议、行程类产品中用户选择的时区比设备时区更可靠因为他可能正在为另一个时区的人安排时间。7. 写在最后一点个人体会时区问题看起来简单实则牵一发动全身。我在实际排查中最大的感触是先把存储层和传输层的时间基准统一为UTC展示层再按需转本地时区这一步做到了80%的时区诡案都可以避免。剩下的20%基本都集中在夏令时规则、旧系统遗留的本地时间存储、以及Windows注册表这类的边缘故障上。如果只是临时查一下某几个城市现在几点公式和在线工具都够用。但如果是写代码、配置服务器、处理全球用户数据一定不要贪图省事省略时区标注。一份清晰准确的时区一览表只是起点真正值钱的是背后那套理解和规范。