结论
| 对比项 | Excel 日期体系 | Unix 时间戳 |
|---|---|---|
| 本质 | 面向人类办公 | 面向操作系统 / 程序 |
| 单位 | 天（浮点数） | 秒（整数） |
| 起点 | 1900-01-01（或 1904） | 1970-01-01 UTC |
| 是否含时区 | ❌ 不含 | ❌ 不含（但解释时用时区） |
| 设计目标 | 表格计算 | 系统时间统一 |
Excel 日期体系（序号时间）
本质是什么？
一个“天数序号”
Excel 并不知道什么是“时间戳”，它只知道：
从某个起点开始，过了多少天
核心特征
| 特征 | 说明 |
|---|---|
| 单位 | 天（小数表示时间） |
| 起点 | 1900-01-01（Windows） |
| 类型 | 浮点数 |
| 是否含时区 | ❌ 完全没有 |
| 面向对象 | 人类（做表的人） |
示例
| Excel 值 | 实际含义 |
|---|---|
1 |
1900-01-01 |
25569 |
1970-01-01 |
45000.75 |
某天 18:00 |
Excel 小数部分：
0.5 = 12:00
0.75 = 18:00
一个“历史包袱”
Excel 错误地把 1900 当成闰年
但为了兼容 Lotus 1-2-3，这个 bug 被保留至今。
👉 所以 Excel 的时间体系是 “人为规则”
Unix 时间戳（绝对时间）
本质是什么？
从某个绝对时刻开始的秒数
1970-01-01 00:00:00 UTC = 0
核心特征
| 特征 | 说明 |
|---|---|
| 单位 | 秒 |
| 起点 | 1970-01-01 UTC |
| 类型 | 整数 |
| 是否含时区 | ❌（但解释时需要） |
| 面向对象 | 操作系统 / 程序 |
示例
| Unix timestamp | 含义 |
|---|---|
0 |
1970-01-01 00:00:00 UTC |
1700000000 |
某个精确时刻 |
为什么“Excel → Unix”总是容易出坑？
原因只有一个：
Excel 的时间“没有时区”，
Unix 的时间“必须解释时区”。
常见坑
| 场景 | 后果 |
|---|---|
| PHP 默认 Asia/Shanghai | 多 +8 小时 |
| PHP 默认 UTC | 正常 |
| 手动 -8 | 换服务器就炸 |
| setReadDataOnly | Excel 格式信息丢失 |
为什么 Excel 不设计成 Unix timestamp？
因为 Excel 出现时：
Unix 还没普及
Excel 面向的是 会计 / 财务 / 文员
“第几天”更直观
所以 Excel 的时间是：
为人服务的时间体系
Unix 时间戳是：
为机器服务的时间体系
时间差异实例
2025-11-11 08:00:00（中国时间，UTC+8）
Unix 时间戳（以 UTC 为基准）
中国时间（UTC+8）→ 转成 UTC 时间：
2025-11-11 08:00:00 CST = 2025-11-11 00:00:00 UTC
Unix 时间戳定义
从 1970-01-01 00:00:00 UTC 起，到目标时间的 秒数：
Unix Timestamp = 1762819200
👉 这是一个绝对值，与服务器时区无关（前提：你传入的是 UTC 时间）
Excel 日期序列值（1900 日期体系）
日期部分:（已包含 1900 闰年 bug）
2025-11-11 → Excel 日期序号 = 45972
时间部分:
08:00:00 = 8 / 24 = 0.3333333333
Excel 最终值:
Excel Time = 45972.3333333333