选择两个城市，实时看时差
默认对比北京与纽约；下拉共 40 座城市，含印度、尼泊尔、伊朗等非整点时区。
时差是两条 UTC 偏移之差
时差并不是靠背下来的数字，而是两条 UTC 偏移之差。理论上地球每 24 小时转 360 度，每 15 度经线对应 1 小时，于是全球划出 24 个整点时区；北京时间取东经 120 度的地方时，固定为 UTC+8，而纽约在标准时是 UTC-5、夏令时是 UTC-4，所以两地的差值会在 13 小时与 12 小时之间切换。本工具不写死任何偏移，而是让浏览器用 Intl.DateTimeFormat 把同一时刻分别格式化到两个时区，再从年月日时分秒反推各自的真实偏移，因此夏令时、历史规则变更都自动生效。
半小时与非整点时区是另一个容易算错的地方：印度 UTC+5:30、伊朗 UTC+3:30、阿富汗 UTC+4:30、尼泊尔 UTC+5:45、缅甸 UTC+6:30，两地相减后会出现 30 分、45 分甚至 15 分的零头。所以结果按分钟计算，不会粗暴地四舍五入成整小时。也要留意 15 度换 1 小时只对理论时区成立，现实中一国采用哪个偏移更多是行政决定：中国横跨五个理论时区却统一使用东八区，俄罗斯则保留多个时区。要查更多组合，可以配合时区换算与世界时钟一起使用。
重叠工作时段怎么用
所谓重叠工作时段，是两个人都在当地时间 9:00 至 18:00 之间的那段窗口。把两座城市的上班时间折算到同一把尺子（这里是北京时间）上再求交集，就能一眼看出哪些钟点适合开会。工具在后台把一天 1440 分钟逐分钟判定：某一分钟在两地的当地时间是否同时落进工作区间，命中的连续分钟合并成一段，再换算成北京时间列出。
举几个具体例子：北京与伦敦冬令时差 8 小时，重叠窗口只有北京时间 17:00 到 18:00 这一小时，恰好是伦敦上午 9 点到 10 点；北京与悉尼相差 2 至 3 小时，重叠窗口长 6 至 7 小时，几乎整个中国上午都可用；北京与洛杉矶、圣保罗这类美洲城市往往没有交集，洛杉矶冬令时只剩北京时间 9:00 到 10:00 的一小时，夏令时则彻底归零。遇到无重叠的情况，务实的做法是轮流迁就：单周由东半球早起，双周由西半球晚睡，并把约定写成两地时间加 UTC 偏移。
常见问题
为什么时差会精确到分钟，而不是整小时？
因为世界上存在非整点时区：印度是 UTC+5:30、伊朗 UTC+3:30、阿富汗 UTC+4:30、尼泊尔 UTC+5:45、缅甸 UTC+6:30。两个这样的时区相减，差值就会出现 15 分、30 分或 45 分的零头，例如新德里与加德满都只差 15 分钟。本工具按分钟计算差值，所以不会把 2 小时 30 分显示成 2 小时。
夏令时切换那天，时差会突然变化吗？
会。夏令时通常在凌晨 2 点把钟拨快或拨回 1 小时，所以切换当天两地时差会跳变 60 分钟。美国东部在 3 月第二个周日进入夏令时，与北京的时差从 13 小时缩到 12 小时，11 月第一个周日再恢复；欧盟在 3 月最后一个周日与 10 月最后一个周日切换。切换当天若跨过凌晨，日期和星期也要重新核对。
为什么两地会差一天？
因为 UTC 偏移不同，同一个瞬间在不同时区可能落在不同的日历日。向西偏移越多，当地日期越靠前：北京比纽约快 13 小时，北京上午 10 点时纽约还是前一天晚上 21 点。工具在每个城市下方单列日期与星期，日期与北京不同时会标色，方便判断跨日。
页面上的时间是实时的吗，数据准不准？
是实时的，页面每秒刷新一次。城市偏移由浏览器内置的 Intl 时区数据即时计算，数据来自 IANA 时区数据库，夏令时起止、历史偏移变更都由浏览器维护。若浏览器版本过旧，个别新调整的规则可能滞后，重要场合建议再以当地官方时间为准。