时间戳转换工具

一个 Unix 时间戳,单纯就是从 1970 年 1 月 1 日 UTC 时间午夜开始经过的秒数——这是几十年前选定的一个任意参考点,此后成了计算机系统内部表示某个时间点近乎通用的默认方式。它的吸引力在于,它把一个日期和时间简化成一个单一的、容易比较、容易存储的整数:判断一个时刻是否早于另一个,只是一次简单的数值比较,而不是一次日历计算,而且存储它所需要的空间是固定的、可预测的,不管这个日期落在哪个世纪。这正是它成为数据库时间戳列、API 响应和日志文件条目背后基础的原因,尽管这个原始数字对直接看着它的人来说毫无意义——而这正是像这样一个转换工具存在的全部理由。

一个表示当前时刻的 Unix 时间戳,按秒算是十位数字,同一个时刻按毫秒表示是十三位数字——多出的三位数字对应千分之一秒的精度。这个位数差异是快速、可靠地判断一个数字属于哪种单位的方法,也解释了两种搞错单位时最常见、也最容易让人困惑的失败模式。把一个毫秒值传给期望秒的代码,会让换算出的日期乘以大约一千倍,落在公元 55000 年左右——明显、离谱地错误。把一个秒值传给期望毫秒的代码,则正好相反:把真实经过的时间除以大约一千,换算出的日期会落在 1970 年附近,这个日期看起来足够合理,有时反而会被误以为是别处的一个真实 bug,而不是单位不匹配。

一个原始的 Unix 时间戳完全不携带任何时区信息——它单纯就是经过的秒数的计数,在地球上任何一个时刻、任何地方都是相同的——把它转换成人类可读的日期,正是需要为了显示目的选定一个时区的那一刻。用 UTC(或者原始时间戳本身,它在定义上就是不依赖时区的)来存储和记录事件,意味着系统里的每一条记录,无论服务器、数据库,还是正在读日志的人身处哪个时区,代表的都是完全同一个时刻。转换成本地时间是一个只在有人真正在查看这个值时才会做出的显示层决定,这也是为什么这个工具把两者清楚地分开:UTC 和 ISO 8601 是值得存储和比较的值,本地时间是值得阅读的版本。

相当一部分较老的基础设施——老旧的 C 代码、一些嵌入式系统、某些较老的数据库列类型——把 Unix 时间戳存储在一个有符号 32 位整数里,这个类型有一个硬性上限:它会在 2038 年 1 月 19 日 UTC 时间 03:14:07 发生溢出,回绕到 1901 年的某个日期,这个 bug 的底层结构和千年虫问题类似,但根源是二进制整数的限制,而不是两位数年份。JavaScript 用 64 位浮点数表示数字,拥有远远更大的余量,不会受到这种特定溢出的影响,所以在这个工具里计算出的时间戳不受影响——需要担心的是最初产生这个待转换时间戳的那个系统,而不是这里正在进行的转换本身。