先判断单位
Unix 时间戳通常表示从 1970-01-01 00:00:00 UTC 起经过的时间。当前年代的秒级值通常约 10 位，毫秒级值约 13 位，微秒级值约 16 位，但位数只是初筛。
| 示例 | 可能单位 | 解释 |
|---|---|---|
| 1700000000 | 秒 | 2023-11-14 22:13:20 UTC |
| 1700000000000 | 毫秒 | 同一时刻的毫秒表示 |
| 1700000000000000 | 微秒 | 部分数据库与日志使用 |
若转换后落在 1970 年附近或远超题目年代，首先检查单位，而不是认为日志损坏。
UTC 与本地时间要同时保留
Unix 数值本身不带时区，但可读日期可能带。分析时建议把所有事件转换成 UTC，并另外记录原日志时区。仅写“09:30”没有意义，应写成包含日期和偏移的形式，例如 2026-09-18T09:30:00+08:00。
不同来源的时间语义
- Web 访问日志可能记录服务器时区或明确偏移。
- JWT 的
iat、nbf、exp通常使用 Unix 秒。 - JavaScript
Date.now()返回毫秒。 - 文件系统时间可能受文件系统精度、复制行为和时钟偏差影响。
- 抓包时间取决于采集设备时钟，可能与服务器日志不同步。
构建事件时间线
为每条证据保留“原值、解析规则、UTC、来源、可信度”。不要只复制转换后的可读时间，因为日后无法检查单位是否选错。
source: access.log
raw: 1700000000
rule: Unix seconds
utc: 2023-11-14T22:13:20Z
note: server clock may be +4s注意时钟偏差
如果多个来源始终相差固定秒数，可能是设备时钟不同步。先估计偏差，再判断事件先后，不要强行修改原始记录。
常见错误
- 把 13 位毫秒值按秒转换。
- 比较没有时区的日期字符串。
- 把文件“修改时间”直接当作行为发生时间。
- 四舍五入后丢失同一秒内的事件顺序。
- 根据当前电脑时区显示结果，却未在报告中说明。
推荐流程
- 保留原始数值和日志行。
- 根据位数与上下文提出单位假设。
- 转换后检查日期是否合理。
- 统一成 ISO 8601 UTC。
- 记录来源时区和可能的时钟偏差。
- 再按时间排序并关联事件。