存储用 UTC
数据库和接口统一保存 UTC 时间或 Unix 时间戳。绝对时间点不依赖用户所在地，排序和比较也更直接。
WORLD CLOCK / TIME ZONE
时区换算器
北京时间下午三点，纽约是几点？把日期、时间和源时区填进来，十个常用时区的本地时间会同时排开。夏令时、跨日和 UTC 偏移都会一起标出，不用再凭记忆加减小时。
RIGHT NOW / 当前世界时间
此刻，世界各地的钟表
下面显示的是当前瞬间在各城市的本地时间，每秒更新。它适合快速判断对方是否在工作时间；需要换算某个具体日期时，用下方的换算器。
北京 UTC+08:00--:--:--
UTC UTC+00:00--:--:--
东京 UTC+09:00--:--:--
新加坡 UTC+08:00--:--:--
迪拜 UTC+04:00--:--:--
伦敦 UTC+00:00--:--:--
巴黎 UTC+01:00--:--:--
纽约 UTC−05:00--:--:--
洛杉矶 UTC−08:00--:--:--
悉尼 UTC+10:00--:--:--
CONVERT A MOMENT
换算一个具体时间
输入的钟表时间按“源时区”解释，结果保留同一个绝对时间点
快捷
换算结果
源时间：—
北京 —
—UTC+08:00
协调世界时 —
—UTC+00:00
东京 —
—UTC+09:00
新加坡 —
—UTC+08:00
迪拜 —
—UTC+04:00
伦敦 —
—UTC+00:00
巴黎 —
—UTC+01:00
纽约 —
—UTC−05:00
洛杉矶 —
—UTC−08:00
悉尼 —
—UTC+10:00
NOT A FIXED +8 / 时区常识
时区差不是
一张固定的加减表
北京全年使用 UTC+8，没有夏令时，所以“北京时间减 8 小时就是 UTC”在日常生活里几乎总成立。但纽约、伦敦、巴黎和悉尼并不是这样：它们一年里会切换一次标准时与夏令时，和北京的时差也随之变化。
纽约在冬令时是 UTC−5，和北京差 13 小时；到了夏令时变成 UTC−4，和北京差 12 小时。伦敦冬天是 UTC+0，和北京差 8 小时；夏天是 UTC+1，和北京差 7 小时。只记住“差 8 小时”或“差 12 小时”，在换季时就会出错。
本页使用浏览器内置的 IANA 时区数据，按时区名而不是缩写来换算。这样可以正确处理历史上的规则变化和当前的夏令时安排。
一个具体例子北京时间 2026-01-15 15:00，纽约是 2026-01-15 02:00（冬令时，UTC−5）；到 2026-07-15 15:00，纽约则是 03:00（夏令时，UTC−4）。
| 城市 | 标准时 | 夏令时 | 备注 |
|---|---|---|---|
| 北京 | UTC+8 | 无 | 全年固定 |
| UTC | UTC±0 | 无 | 基准时间 |
| 东京 | UTC+9 | 无 | 全年固定 |
| 新加坡 | UTC+8 | 无 | 全年固定 |
| 迪拜 | UTC+4 | 无 | 全年固定 |
| 伦敦 | UTC+0 | UTC+1 | 3 月—10 月 |
| 巴黎 | UTC+1 | UTC+2 | 3 月—10 月 |
| 纽约 | UTC−5 | UTC−4 | 3 月—11 月 |
| 洛杉矶 | UTC−8 | UTC−7 | 3 月—11 月 |
| 悉尼 | UTC+10 | UTC+11 | 10 月—次年 4 月 |
表中是标准时与夏令时的常见偏移，具体切换日期由当年法规决定。换算结果以所选日期对应的 IANA 规则为准。
NAMES AND ABBREVIATIONS / 命名
为什么不建议只写
CST、EST？
时区缩写并不唯一。CST 可以指中国标准时间、美国中部标准时间，也可以是古巴标准时间；EST 也不总是等于 UTC−5。缩写适合给人快速阅读，不适合写进程序或接口。
传输写偏移
如果需要传本地时间，使用 RFC 3339 写法，例如 2026-01-01T08:00:00+08:00。偏移让接收方无需猜测。
程序用 IANA
在代码里写 Asia/Shanghai、America/New_York 这样的时区名，而不是 CST 或 GMT+8。
MEETING CHECK / 会议核对
发会议邀请前，
把这三行写完整
第一行写绝对时间：带上 UTC 偏移，例如“2026-03-10 15:00 +08:00”。
第二行写各城市本地时间：北京 15:00、伦敦 07:00、纽约 03:00。日期不同的时候，把日期也写上，不要只写“下午三点”。
第三行写时区名：例如“Asia/Shanghai / Europe/London / America/New_York”。这样即使对方所在地区临时调整夏令时，也能按规则重新计算。
注意跨日北京上午的会议，可能是洛杉矶前一天的傍晚；悉尼的日期也可能比北京早一天。换算结果里的“+1 天 / −1 天”提示就是为这种情况准备的。
TIME ZONE FAQ / 问答
时区换算的常见疑问
时区问题往往不是算错，而是“把哪个时间当成源”。先确定输入的是哪座城市的钟表时间，结果才有意义。
为什么北京和纽约有时差 12 小时，有时差 13 小时？
北京全年 UTC+8。纽约冬令时 UTC−5，相差 13 小时；夏令时 UTC−4，相差 12 小时。差别来自纽约的夏令时，不是北京时间变了。
为什么结果里会出现“+1 天”？
因为两个城市的日期不同。比如北京已经是 1 月 2 日上午，洛杉矶可能还停留在 1 月 1 日下午。日期差和小时差要一起看。
时区换算和 Unix 时间戳是什么关系？
时间戳表示绝对时间点，时区只影响它如何显示。换算时先由源时区得到时间戳，再把同一个时间戳用目标时区格式化。绝对时间点不变，钟表读数改变。
这个页面能处理历史日期吗？
可以。浏览器内置的 IANA 数据包含许多历史时区规则，但不同浏览器版本的数据新旧不同。涉及很久以前的历史日期或法律文件时，建议再查权威时区数据库。
BACK TO THE NUMBER
换算完时区，再核对时间戳
跨时区系统里，最稳妥的协作方式是传递 Unix 时间戳或带偏移的 ISO 时间。把结果带回转换器，确认数字与显示时区都一致。