Unix 时间戳转换指南：Epoch 时间、秒与毫秒之争

Unix 时间戳数的是从 1970 年 1 月 1 日 00:00:00 UTC 起经过的秒数，这个瞬间被称为 Unix 纪元（epoch）。没有日历字段，没有月份名称，没有夏令时调整，也没有时区偏移后缀。就只有一个整数，以每秒加一的速率，永远往上跳。

这种简单正是它的意义所在。时间被压缩成一个数字之后，计算机就能紧凑地存储它，用一次减法比较两个时刻，用普通的数值排序给事件排序，全程都不必操心日历和时区。闰年、本地偏移这些麻烦事被推到了展示环节，而那时候反正有人在看。日期是给人看的，时间戳才是机器之间真正传递的东西。

多数语言和平台数的是秒。C、Python、PHP，以及 Unix shell 里的 date 命令，产出的都是一个 10 位数字，眼下这个数在约 17 亿上下。JavaScript 是那个著名的例外：Date.now() 返回的是自同一纪元起的毫秒数，也就是一个 13 位数字。这两种约定总是碰面，因为一个应用的前端，往往要跟用别的语言写的后端打交道。

两种值都不会自报单位，数字看上去又足够相似，扫一眼就混过去了。把 13 位的毫秒值喂给一个按秒计算的转换器，你会落到几万年以后；反过来把 10 位值送进去，则会停在 1970 年 1 月，也就是纪元之后的第几周。所以当转换出来的日期荒谬得离谱时，先数一数位数，再去怀疑别的。

常有人担心：在东京记录下的时间戳，被法兰克福的服务器读取时会不会变成另一层意思？不会。这个数字永远以 UTC 为基准，在地球上任何地方都完全一致，因为它数的是从某个固定瞬间起的秒数，而不是在描述某个本地日历上的位置。

随时区变化的，只有给人看的那部分显示。同一个时间戳在不同时区会显示成不同的钟点：柏林已是傍晚，纽约还是清晨，可底下那个数字纹丝不动。所以当一个时间戳看起来差了好几个小时，数字本身通常没问题，是显示端把它转换到了某个谁也没料到的时区——那是渲染层面的决定，不是数据问题。

纪元就是零点，时间从它向两个方向延伸。负的时间戳不过是 1970 年 1 月 1 日之前的某个时刻，而这正是出生日期、历史档案和老旧任务日志会遇到的情况。那个负号没有任何特殊或畸形之处；能正确处理它的转换器，只是把这个格式该有的样子做到位了，谈不上什么额外恩惠。

另一端的边界在未来。用 32 位有符号整数存储时间的系统，会在 2,147,483,647 这个数上用尽空间，它对应 2038 年 1 月 19 日 03:14:07 UTC。再过一秒，数值溢出并翻转成负数，时钟看起来就像一下跳回了 1970 年之前。这就是 Y2038 缺陷，在结构上和 Y2K 属于同一类问题：一个存储上的假设，活得比它的设计者还久。用 64 位整数存时间就能彻底避开它，这也是多数现代系统早已悄悄完成切换的原因。

Unix 时间戳转换器必须支持双向转换，我们的就支持。粘贴一个时间戳，得到可读的日期；或者选好日期和时间，换回它对应的时间戳。结果里会同时给出秒和毫秒两种形式，前面说的那个数位数陷阱，于是成了看得见的东西，而不是靠猜。

这就覆盖了日常的大部分场景：读日志文件、解码数据库导出里的行、查文件修改时间、理解 API 响应中的日期字段。转换在浏览器本地完成，任何东西都不会被上传。单独一个时间戳本身很少谈得上敏感，但装着它们的日志行和数据库记录往往就是敏感的；本地转换让你能解码这些内容，而不必把内部数据粘进一个从没听说过的服务器。