使用 IANA 时区数据库转换时间
时区转换是为完全相同的真实世界时刻，在第二个地点求出对应的墙上时钟时间。 输入日期和时间，选择其所在时区，再选择您想转换到的目标时区——此计算器将显示该地对应的日期和时间、两个时区当前相差的小时数，以及其中任一时区当前是否处于夏令时。
这不仅仅是简单的小时加减法。时区并非都固定在整点相对 UTC 的偏移上（有些位于半小时甚至 45 分钟的刻度上），而且许多时区每年会因夏令时而改变自身偏移量两次——不同国家在不同的日历日期变更，有些地方则根本不采用夏令时。要正确处理这一点，需要每个时区实际的、有时由法律更新的规则，而不仅仅是一张固定的小时偏移表。
计算公式
此计算器没有使用固定公式，而是使用了 IANA 时区数据库——这是权威的、持续维护的每个时区规则记录，您的网络浏览器和几乎所有计算机操作系统都已内置了这份完整副本。转换本身分三步进行：
- 将您输入的日期和时间与”源”时区结合，求出其代表的确切真实世界时刻（以 UTC 表示）。
- 使用”目标”时区自身当前的规则（包括该特定日期是否适用夏令时），查询同一 UTC 时刻在该时区时钟上对应的读数。
- 报告两个时区当前 UTC 偏移量之间的差异，以及转换后的时间是否落在了不同的日历日上。
举例说明
将纽约上午 12:00转换为伦敦时间，在一月份（冬季，两个时区均处于标准时）：
- 纽约（东部标准时间）在一月份为 UTC−5。
- 伦敦（格林尼治标准时间）在一月份为 UTC+0。
- 差异为 5 小时——伦敦更快——所以纽约的上午 12:00 就是当天伦敦的下午 5:00。
在七月份，两个时区都会切换到夏令时（纽约切换为东部夏令时，UTC−4；伦敦切换为英国夏令时，UTC+1）——各自的偏移量发生了变化，但由于两个时区同步移动，5 小时的差异和转换后的时间保持完全不变。
需要考虑的关键因素
- 在不同日历日期切换夏令时的两个时区，每年可能会有几周时间差发生临时变化。 例如，美国和 欧盟并不在同一天调整时钟——在这段短暂的窗口期内，美国某城市与欧洲某城市之间通常的时差可能 比一年中其他时间多或少一个小时，这是国际通话或旅行中一个真实、容易被忽略的时间陷阱。
- 并非每个时区相对 UTC 的偏移量都是整数小时。 一些地区（例如印度，UTC+5:30，或澳大利亚 部分地区，UTC+9:45）使用半小时甚至 45 分钟的偏移量——这正是为什么简单的「数小时」方法对某 些时区组合会失效，也是为什么本计算器依赖完整的 IANA 数据库，而不是一张基础的偏移表。
- 一个时区的规则——包括是否以及何时采用夏令时——是由各国政府自行制定的，并且偶尔会发生变 化。 近年来一些国家和地区调整过其夏令时政策，甚至完全废除了夏令时——使用最新维护的时区数 据库（例如本计算器所依赖的 IANA 数据库），而不是一张静态、手工维护的表格，是随着这些规则 演变而保持转换工具准确性的关键。
- 转换一个恰好在夏令时切换点附近的时间，在目的地时区可能会落在一个重复出现或根本不存在的时 刻。 「春季提前」的切换会直接跳过一个小时（例如凌晨 2:00 可能直接跳到凌晨 3:00），而 「秋季回退」则会重复一个小时——恰好在这类切换点附近输入的时间，需要格外小心才能正确解读。
常见错误
- 使用”UTC-5”这样的固定偏移量，而不是实际的城市或地区。 单纯的偏移量并不知道您关心的日 期是否适用夏令时——同一个”UTC-5”地点在一年中的某段时间实际上可能是 UTC-4，导致转换结果在不 知不觉中偏差一个小时。
- 假设两个时区全年始终保持相同的时差。 在不同日历日期开始和结束夏令时的时区（例如美国和 欧盟）在每年春秋两季都会有几周时间，时差与平时略有不同。
- 忽略转换后时间上的日期变更标记。 相距足够远的时区之间的转换，结果可能落在前一天或后一 天——不核实就把转换后的时间当作”同一天”，是错过电话或会议的常见原因。