理解时区偏移量
下表列出了按IANA时区数据库确定的所支持时区及其标准UTC偏移量和夏令时情况。实行夏令时的时区在每年部分时间会比其标准偏移量快一小时。
| 时区（IANA名称） | 城市标签 | 标准偏移量 | 夏令时 |
|---|---|---|---|
| UTC | UTC | UTC+0 | 无 |
| Europe/London | 伦敦 | UTC+0（GMT） | 夏季为UTC+1（BST） |
| Europe/Berlin | 柏林 | UTC+1（CET） | 夏季为UTC+2（CEST） |
| Europe/Paris | 巴黎 | UTC+1（CET） | 夏季为UTC+2（CEST） |
| Africa/Johannesburg | 约翰内斯堡 | UTC+2（SAST） | 无 |
| America/New_York | 纽约 | UTC−5（EST） | 夏季为UTC−4（EDT） |
| America/Chicago | 芝加哥 | UTC−6（CST） | 夏季为UTC−5（CDT） |
| America/Denver | 丹佛 | UTC−7（MST） | 夏季为UTC−6（MDT） |
| America/Los_Angeles | 洛杉矶 | UTC−8（PST） | 夏季为UTC−7（PDT） |
| America/Sao_Paulo | 圣保罗 | UTC−3（BRT） | 无（夏令时已于2019年废止） |
| Asia/Dubai | 迪拜 | UTC+4（GST） | 无 |
| Asia/Kolkata | 加尔各答／孟买 | UTC+5:30（IST） | 无 |
| Asia/Shanghai | 上海／北京 | UTC+8（CST） | 无 |
| Asia/Tokyo | 东京 | UTC+9（JST） | 无 |
| Asia/Singapore | 新加坡 | UTC+8（SGT） | 无 |
| Australia/Sydney | 悉尼 | UTC+10（AEST） | 南半球夏季为UTC+11（AEDT） |
| Pacific/Auckland | 奥克兰 | UTC+12（NZST） | 南半球夏季为UTC+13（NZDT） |
- 换算使用的是浏览器内置的IANA时区数据中当天的偏移量，因此夏令时的切换会被自动应用，无需手动修正。
- 北半球和南半球在一年中相反的半段实行夏令时，因此伦敦与悉尼之间的时差会随季节在9小时到11小时之间变化。
- 并非所有偏移量都是整小时——印度（IST）为UTC+5:30，其他一些地区也采用+5:45或半小时的偏移量。
- 时区规则会因各国政府的决定而改变（圣保罗已于2019年废止夏令时）；IANA数据库每年都会多次更新，以跟踪此类变化。
什么是时区换算？
时区换算是通过两个时区相对协调世界时（UTC）偏移量之间的差值，把某地区的时刻换算为另一地区同一时刻的当地时间。每个时区都由其相对UTC的偏移量来定义——约翰内斯堡全年为UTC+2，而纽约在冬季为UTC−5，在夏令时期间为UTC−4。
时区规则由IANA时区数据库（也称tz数据库或zoneinfo）维护，这是全球操作系统和编程语言共同使用的参照数据集。各时区以代表性城市命名，如America/New_York、Asia/Tokyo，正是因为偏移量和夏令时规则由各地政府自行制定并会随时间变化；该数据库记录了每个地区完整的历史和现行规则。
夏令时正是两个城市之间时差并非恒定的原因。伦敦和纽约通常相差5小时，但在每年春秋两季各有几周——当其中一方已经切换而另一方尚未切换时——差值会变为4小时。本计算器会使用浏览器内置的IANA数据，根据当天日期计算两个时区各自的偏移量，因此夏令时会被自动处理，无需手动调整。
如何使用本时区换算器
- 以24小时制HH:MM格式输入时间——例如14:00。
- 从支持的17个城市中选择源时区（即该时刻所在的时区）。
- 选择你想要换算成的目标时区。
- 查看换算后的时间及当前的时差；标记为（+1天）或（−1天）表示换算结果落在第二天或前一天。
时区换算背后的公式
换算器会根据当天日期，从IANA数据中确定每个时区当前的UTC偏移量，计算两者之差，再将其加到源时间上。结果会在24小时制内循环，若相加后跨越了午夜（无论向前还是向后），会标记出日期偏移。
计算示例：伦敦时间14:00，在英国夏令时期间换算为约翰内斯堡时间。伦敦为UTC+1（BST），约翰内斯堡为UTC+2（SAST），因此时差为+1小时，结果为15:00。在冬季进行同样的换算会得到16:00，因为伦敦恢复为UTC+0，而约翰内斯堡没有夏令时。
常见错误
- 全年使用固定的时差——像伦敦与纽约这样都实行夏令时的城市对，时差会在一年中于4小时和5小时之间变化。
- 忽略日期可能会变化——洛杉矶时间20:00在奥克兰已经是第二天的下午（7月为15:00，1月为17:00）；安排日程时请留意（+1天）标记。
- 以为每个时区都是相对UTC的整小时偏移——印度采用UTC+5:30，因此纽约到孟买的时差根据美国是否实行夏令时，会是9.5或10.5小时。
- 混淆时区缩写——“CST”在芝加哥指中部标准时间，而在上海指中国标准时间；IANA的城市命名方式避免了这种歧义。
- 在夏令时切换前后安排日程却不加核实——只有一方已经切换的那几天，正是最容易错过会议的经典场景。
常见问题
如何在两个时区之间换算时间？
分别找出每个时区当前的UTC偏移量，求出差值，再将其加到源时间上。例如，伦敦时间14:00（英国夏令时期间为UTC+1）换算为约翰内斯堡时间（全年UTC+2）需要加1小时，得到15:00。本计算器会使用IANA时区数据自动完成这一查找，包括夏令时的调整。
本换算器能处理夏令时吗？
能。偏移量是根据浏览器内置的IANA时区数据库，按当天日期计算得出的，该数据库记录了每个时区的夏令时规则。当伦敦处于BST、纽约处于EDT时，时差为5小时；在每年春秋两季只有一方已经切换的短暂窗口期内，会自动应用正确的4小时时差。
什么是IANA时区数据库？
IANA时区数据库（tz数据库或zoneinfo）是全球各地区时区和夏令时规则的参照汇编，由互联网数字分配机构维护。各时区以代表性城市命名，例如America/New_York或Asia/Tokyo，该数据库会随着各国政府调整规则而每年多次更新。
为什么我换算后的时间显示（+1天）？
（+1天）标记表示换算后的时间落在下一个日历日。把洛杉矶时间20:00换算为东京时间，需要加16或17小时（取决于美国是否实行夏令时），结果落在第二天的12:00或13:00。类似地，（−1天）表示目标地仍处于前一天。
为什么印度的时区偏移量不是整小时？
印度标准时间由国家决定采用UTC+5:30——时区偏移量是政治选择，而非地理上的必然结果。其他非整小时偏移量也存在，例如尼泊尔为UTC+5:45，澳大利亚部分地区为UTC+9:30。这也是时区运算应使用真实时区数据、而不是假定整小时时差的原因之一。
为什么两个城市之间的时差不总是固定的？
因为不同国家的夏令时开始和结束日期各不相同，南北半球实行夏令时的季节也正好相反。伦敦和悉尼在南半球夏季相差11小时，在北半球夏季相差9小时，在两者之间的短暂过渡期则相差10小时。像约翰内斯堡、迪拜和东京这样不实行夏令时的时区，全年相对UTC保持固定偏移。
参考文献
- IANA Time Zone Database (tz database) — the reference time zone and daylight-saving rules. iana.org/time-zones.
- ISO 8601 — Date and time — Representations for information interchange (UTC offsets). International Organization for Standardization.
- NIST — Time and Frequency Division: Coordinated Universal Time (UTC). nist.gov.