要点：Unix 时间戳是自 1970 年 1 月 1 日午夜 UTC 起经过的秒数。日志和 API 使用它，因为它无歧义且与时区无关。两处易错：区分秒与毫秒；记住原始数字始终是 UTC，直到你把它转换到某个本地时区。
跨服务器比较条目时，一个纯整数比格式化日期更易推理：没有时区、没有区域设置、没有夏令时歧义。但正是这种“原始”，使得一个缺少上下文的时间戳容易被读错。
时间戳为何从 1970 年开始
Unix 纪元是 1970 年 1 月 1 日午夜 UTC，由贝尔实验室早期 Unix 开发者选作简单而固定的基准点。每个 Unix 时间戳就是自那一刻起的秒数，使得算术——“这两个事件之间过了多久？”——成为一次简单的减法。
是秒还是毫秒？
这是读日志时最常见的错误。经验法则：若数值超过 11 位（大于约 10¹¹），几乎肯定是毫秒。当前以秒计的时间戳约为 17 亿（十位）；同一时刻以毫秒计约为 1.7 万亿（十三位）。把毫秒值喂给按秒解析的程序，你会落到数万年后的未来。
时间戳始终是 UTC
Unix 时间戳编码的是一个绝对时刻，而非本地时钟时间。要展示给人看，你需应用一个时区：同一数字既是“伦敦 14:30”，也是“纽约 09:30”。要干净地双向转换，就要明确所指时区：好的转换器使用标准 IANA 时区数据库与 Intl.DateTimeFormat API，使该日期的偏移（含夏令时）正确。
凡是存储或分享，都用 ISO 8601
当时间戳既要人类可读又要机器安全时，使用 ISO 8601：2024-03-15T14:30:00.000Z。T 分隔日期与时间，Z 表示 UTC。它作为纯文本能正确排序，也为下一位读者消除了秒与毫秒的猜测。
关于 2038 的说明
把时间戳存为有符号 32 位整数的系统，会在 2038 年 1 月 19 日溢出。多数现代平台已改用 64 位时间，但遇到老旧系统或定宽数据库列时，知道这一点很有用。
一个实用流程
- 从日志或 API 响应中复制原始值。
- 粘贴到 时间戳转换器，它自动识别秒或毫秒，并按所选时区显示日期。
- 在相减前，把要比较的两个事件转换到同一时区（或都保持 UTC）。
- 以 ISO 8601 存储或分享结果，避免再次引入歧义。若在为工单整理日志片段，可搭配字符计数器。
需要避免的常见错误
- 在同一比较中混用秒与毫秒。
- 以为原始时间戳已是本地时间。
- 比较以不同时区呈现的两个事件。
- 使用无法支持到 2038 年之后的定宽 32 位时间字段。