什么是 ISO 8601？
ISO 8601 是规定如何把日期时间写成"无歧义文本"的国际标准。这是你的 API 应当接受的格式、数据库列应当存储的格式、日志应当输出的格式——任何其他写法，第一次跨国通话就会出现 YYYY-MM-DD 与 MM/DD/YYYY 的混战。
示例：
2026-08-27T14:35:00+09:00
拆成四部分：
| 部分 | 含义 |
|---|---|
2026-08-27 |
扩展格式的日期（年-月-日）。 |
T |
日期和时间的字面分隔符。 |
14:35:00 |
24 小时制的时间（时-分-秒）。 |
+09:00 |
相对 UTC 的时区偏移。 |
为什么这个格式是系统层面的赢家
它作为文本是可直接排序的——字典序和时序一致。2026-08-27 排在 2026-08-28 前，2026-08-27T14:00:00Z 排在 2026-08-27T14:35:00Z 前。日志缓冲区用文本写出也能直接搜索和排序，不必解析。
它跨文化无歧义。01/02/2026 在美国是 1 月 2 日，在几乎所有其他地方是 2 月 1 日。2026-01-02 在任何地方都是 1 月 2 日。
它被广泛支持。主流语言的日期库都能解析；大多数默认输出 ISO 8601；所有 SQL 数据库都认识；所有现代文件格式都用它存时间戳。
实际工程里你会遇到的变体
不必每次都写全。ISO 8601 允许若干简写：
2026— 仅年2026-08— 年和月2026-08-27— 仅日期2026-08-27T14:35— 日期加分钟时间2026-08-27T14:35:00— 日期加秒时间2026-08-27T14:35:00.123— 含毫秒2026-08-27T14:35:00Z— UTC 简写（Z等价于+00:00）2026-08-27T14:35:00+09:00— 显式偏移
Z 形式（有时称为"祖鲁时间"）是大多数系统在想要用 UTC 又不想带 :00 这种偏移尾巴时的输出。
常见坑
- 夏令时。ISO 8601 存的是偏移，不是时区。
2026-08-27T14:35:00+09:00一旦你所在司法管辖区结束夏令时，就变模糊了。若你想表达"每天这个挂钟时间"，请存时区标识符（Asia/Tokyo）而不是偏移。 - 闰秒。ISO 8601 不编码闰秒。大多数民用系统忽略它。
- 负年份。ISO 8601 延伸到过去用
-0001表示公元前 2 年、0000表示公元前 1 年。天文学界用另一种约定。 - 没有偏移意味着本地。裸
2026-08-27是一个日历日期，根本没有时间；给它加上时间却不附偏移，是未定义行为。
工具
要把 epoch 时间戳转 ISO 8601 字符串（以及反方向），用 Epoch to DateTime——浏览器内跑，无上传。
跨页面看时间和调度主题，见 Time and Cron hub。
另见
- Cron 表达式 — ISO 8601 的时间侧搭档
- JSON 转 CSV — 当你的时间戳嵌在 JSON 导出里
- UTC vs GMT vs EST — 实用的偏移换算