时区计算器

目标墙上时间 = 出发地墙上时间 − 出发地 UTC 偏移 + 目的地 UTC 偏移；偏移差 = 目的地偏移 − 出发地偏移；天数差 = 目的地日期 − 出发地日期

date

出发地的日历日，写成 YYYY-MM-DD。这是那边的那一天，不是你此刻所在地方的那一天

time

出发地的墙上时间，24 小时制的 HH:MM 或 HH:MM:SS。秒可以省略，但结果里一定会显示

fromZone

你所填时刻所属的时区。22 个 IANA 时区，按城市名而不是按偏移排列——偏移属于某个刹那，不属于某个地方

toZone

要换算到的时区。与出发地是同一份 22 个选项

toTime

目的地时区的墙上时间，恒带秒。这是本页的主结果

toDate

目的地时区的日历日，不一定等于你填的那一天——这正是「天数差」这个输出存在的理由

toWeekday

目的地时区的星期几，用 0（周日）到 6（周六）的序号给出

fromOffset

换算出的那个刹那，出发地距 UTC 多少，写成 UTC±HH:MM

toOffset

同一个刹那，目的地距 UTC 多少。两个偏移都按那一刻读，所以哪里正在夏令时就都算在里面

offsetDifference

目的地偏移减出发地偏移，单位小时。负数表示目的地更靠西

dayShift

−1、0 或 +1：目的地是前一天、同一天，还是后一天

两个地方同时牵扯进来、而时钟必须可信的时候用：约一场跨洋电话、看一班航班落地是不是当天、读一份用 UTC 写的服务器日志、或者弄清对方说的「周日早上」到底是你的周日晚上还是周一凌晨。天数差是手算最容易错的那一步，因为它不是两个城市之间固定的性质——同一对城市之间一月差 12 小时、七月差 11 小时。本页换算的是你已经拿到的那个时刻：它不告诉你某个地方属于哪个时区（下拉框固定 22 个），也不管飞行时长、行程耗时和提醒。

1. 上海中午 12 点，纽约还是前一天

   1. 一月的上海是 UTC+08:00，所以当地中午 12:00 就是 1 月 15 日 04:00 UTC
   2. 纽约这时用 EST，UTC−05:00，04:00 UTC 在那边是 23:00
   3. 23:00 还没过午夜，所以那边的日期是 1 月 14 日，比填进去的那一天早一天，天数差报 −1
   4. 2026 年 1 月 14 日是星期三，所以星期序号是 3
   5. 两个偏移相差 −13 小时：08:00 与 −05:00 差 13 小时，目的地更靠西所以取负

   这是本页的默认状态，也是最容易让人愣一下的一条：上海中午发出去的一句话，落到纽约是前一天的深夜。手算时用的那条「上海比纽约快 12 或 13 小时」在这里要取 13；到了七月同样的两个城市只差 12 小时，因为纽约在夏令时而上海不在。

2. 不存在的墙上时间：纽约 2026 年 3 月 8 日 02:30

   1. 这一天纽约的钟在本地 02:00 往前拨一小时，02:00 直接变成 03:00，所以 02:00 到 03:00 之间的这半小时从来没有发生
   2. 填进去的 02:30 因此不存在。本页按 IANA 规则对这种「空洞」的处理是往前后移，得到 EDT 的 03:30
   3. 2026 年 3 月 8 日是星期日，所以星期序号是 0
   4. 因为解出来的刹那已经属于 EDT，出发地偏移报的是 UTC−04:00，而不是 02:30 在前一天所对应的 UTC−05:00
   5. 上海是 UTC+08:00，比 EDT 快 12 小时，03:30 换成 15:30 同一天

   填进去的时刻旁边那个偏移看起来「不对」，原因就在这里：02:30 在冬天的纽约是 UTC−05:00 的时刻，可这一个 02:30 落在拨快之后的空洞里，它解出来的刹那属于 EDT，于是报 UTC−04:00。本页对空洞与重复一律按 IANA 的规则读，并且不会拒绝输入、也不会提示——所以结果总会出来，而这一条值得读第二遍。

3. 两边都在夏令时：7 月 4 日伦敦 → 洛杉矶

   1. 七月伦敦用 BST，UTC+01:00，所以那边 09:30 是 08:30 UTC
   2. 洛杉矶用 PDT，UTC−07:00，08:30 UTC 在那边是 01:30
   3. 两个偏移相差 8 小时；冬季同样是 8 小时，但那是另一组 8——一月伦敦是 UTC+00:00、洛杉矶是 UTC−08:00
   4. 两个偏移都含各自的夏令时，所以出发地报的是 UTC+01:00 而不是 UTC+00:00
   5. 日期没有变，天数差是 0；2026 年 7 月 4 日是星期六，星期序号 6

   拿标准偏移（0 与 −08:00）来算，这里得到的时差与墙上时间完全一样——所以这个错法在这一条上不露头，要到换季前后那几天才现形。三月里两个时区在同一个星期朝相反方向拨钟，那几天固定偏移的规则会整整错一小时。

4. 奥克兰的新年，在 UTC 还是去年

   1. 一月的奥克兰用 NZDT，UTC+13:00，所以当地午夜 00:00 是 2025 年 12 月 31 日 11:00 UTC
   2. 换成 UTC 就同时跨过了日界与年界
   3. 目的地日期是 2025 年 12 月 31 日；天数差 −1 是按天序号相减算出来的，不是把日期字符串拿来比大小
   4. 2025 年 12 月 31 日是星期三，星期序号 3
   5. 偏移差 −13 小时：目的地 UTC 更靠西

   「往西就是昨天」这句话并不成立。这里 −13 小时跨过了午夜，上海到纽约那 −13 小时同样落到前一天，而伦敦到纽约的 −5 小时就不会。星期几报的是目的地的那一天，所以填进去的是星期四，报出来的却是星期三。

本页覆盖 1970 到 2100 年、22 个时区，不是 IANA 数据库里的全部时区。下限定在 1970 是有意的：那之前数据库记的是当地实际使用的地方平时——上海曾经是 UTC+08:06，蒙罗维亚用过带秒的偏移——那些答案是正确的，看上去却像本页算错了。不存在的时刻与重复的时刻按 IANA 规则解释（春季往前拨造成的空洞往前后移，秋季重复的那一小时取靠前的一次），不做拒绝，也不提示，所以换季前后那几天请对着结果旁边的两个偏移核对。本页不根据地名推断时区——两个下拉框都是固定的 22 项。它也不知道你本机在哪个时区，不算飞行时长与行程耗时，不涉及闰秒（UTC 本身不带闰秒，与闰秒被加进 UTC 是两件事）。

两地的时间差是多少？

两地的时间差不是一个固定数，本页给出的偏移差是你所填日期当天的那个。同一对城市可能一月差 13 小时、七月差 12 小时，因为其中一边实行夏令时而另一边不实行。所以「上海和纽约差几个小时」这个问题必须带上日期问，这也是本页把日期做成必填字段的原因，而不是留一个「按今天算」的开关。

跨时区会议怎么排？

把会议按它被提出的那个时区填进去，再逐个换到每个参会方的时区。排跨时区会议时真正有用的往往不是小时差而是天数差：伦敦上午 9 点的会在东京是当天 18:00，在纽约却是 04:00，而决定这个邀请合不合理的是那个 04:00。本页同时报出日期与星期几，所以一场会落在对方的周末上也能看出来。

夏令时会自动算进去吗？

会，两边都算，而且算的是你填的那一天而不是今天。夏令时不是一个时区的属性，而是一个时刻的属性：结果旁边的两个偏移是 IANA 规则给那个刹那的值，所以同一对城市一月与七月会差出一小时。本页不假设当前日期，因此为明年三月算出来的结果里已经包含明年三月的那次切换。

为什么时区偏移有时和我预期的不一样？

因为结果旁边的偏移属于解出来的那个刹那，不属于你填进去的那个墙上时间。在拨钟那天，被跳过的那一小时并不存在，填在那一小时里的时刻会被读成它之后的那一刻——所以纽约春季切换日的 02:30 报的是 UTC−04:00（EDT），而不是 02:30 在前一天所对应的 UTC−05:00。两句话说的是同一个刹那，只是一个报的是当时真正生效的偏移。

我这边是周三，那边现在是哪一天？

这要同时看时刻和两个时区，所以本页两个都问。往东跨过日界线会多出一天，往西换够小时数就会少掉一天。天数差字段直接用 −1、0 或 +1 回答这件事，而星期几字段报的是目的地的那一天，于是对方有没有已经走到你正在问的那一天，一眼就能看出来。亚洲/上海到美洲东岸这一类最常见的组合，中午 12 点换过去通常是前一天。

• 科普中国：北京时间 — 科普中国（东八区区时与国家授时中心的来源）
• 夏时制：节能还是「添乱」？ — 新华网（1986–1991 年全国实行夏令时、1992 年暂停的出处）
• IANA Time Zone Database — Internet Assigned Numbers Authority（本页 22 个时区名与消歧规则的来源）