一句话定义：时区与时间处理，是把「绝对时刻」和「人看到的钟点」分开管理的一整套约定——机器存绝对时刻（通常是 UTC，协调世界时 Coordinated Universal Time），只在展示的那一刻才翻译成某个地区的本地时间。
为什么不能只存「几点」
时间戳记录的是「从某个基准点起过了多少秒」，它本身没有「几点」这个概念。可以理解成快递单号：单号唯一确定一个包裹，但「几点送到你家」要看你家在哪。UTC 就是全球共用的那套单号系统，本地时间只是快递员跟你说的「下午三点到」。
三个最容易出错的地方：
1. 把本地时间当绝对时间存。 「2025-06-01 09:00」这种不带时区的字符串（naive datetime）在系统之间传递时没有任何确定含义，谁读谁猜。稳妥做法是存绝对时刻，同时单独记下时区 ID（Time Zone ID，如 Asia/Shanghai），而不是把 +08:00 写死——偏移量只是某一刻的快照，时区规则变了它不会跟着变。
2. 「明天」是相对词。 用户说「明天提醒我交报告」，助手得先知道用户此刻在哪个时区、当地几点。UTC 日期和本地日期能差一天：UTC+14 与 UTC−12 相差 26 小时，同一瞬间两地日期不同。所以「明天」「今晚」「下周一」这类说法，必须绑定用户时区和当前本地时间再解析，否则排出来的可能是今天或后天。
3. 夏令时（DST，Daylight Saving Time）。 部分地区的时钟每年拨快拨慢一小时，规则由当地政府决定，还会变。切换当天，本地 02:00–03:00 可能根本不存在（春季前跳），也可能出现两次（秋季回拨）。给这个区间排日程必须有明确策略：顺延、取切换前还是切换后。重复事件同理——「每天 9 点开会」通常按固定本地钟点算，而不是每 24 小时一次。
| 表示方式 | 是什么 | 适合做什么 | 主要风险 |
|---|---|---|---|
| UTC / 时间戳 | 绝对时刻 | 存储、排序、算间隔 | 直接给人看会懵 |
| 偏移量 +08:00 | 某时刻与 UTC 的差 | 传输瞬间快照 | 规则变化后失效 |
| 时区 ID | 一套历史与未来规则的名字 | 长期日程、重复事件 | 依赖时区数据库更新 |
| 本地时间字符串 | 墙上的钟点 | 展示 | 不带时区就有歧义 |
给从业者：用带时区意识的类型（aware datetime），别用裸字符串；解析自然语言时间时把用户时区、当前本地时间当必填参数；DST 边界写成测试用例；拿不准就追问一句「您所在时区是？」，比猜便宜得多。时区数据库会更新，具体边界以官方发布为准。
给普通人：约会议别只说「上午十点」，附上城市或 UTC；跨国协作的日历邀请里，时区字段比备注更重要。