时间戳会溢出Overflow吗？啊？用时间戳存时间？会不会不靠谱？难道时间戳不会溢出吗？放心放心，完全不会的哟。放心大胆

时间戳会溢出吗？

我的答案是，会，但是不用担心。

时间戳 (timestamp) 是一种统一的表达时间的办法。它的值等于从英国格林威治时间(UTC-0) 1970.1.1 00:00:000 开始算起的毫秒数。

那这样的话，每次算两个时间点中间相差多少的时候，就拿 timestamp 相减就行了，完全没有时差的影响。

相信大家不难发现，时间是一直在流逝的，这个 timestamp 也是递增的。理论上时间是无限的，而计算机存储的位数是有限的。那会不会有一天，存储溢出了，出现了类似千年虫的问题？

（也就是溢出之后，有可能会使得系统表达的时间回流到1970年之前的时间，从而由于时间对不上而产生一些问题）

理论上，是会的，但是完全不用担心，因为我们一般会用64位来存储时间戳

64位能存多少年呢？我们来算一算。算上符号位，我们最多可以存这么多毫秒：

2^{64-1} - 1 = 9223372036854775807 (ms)

也就是：

\frac{9223372036854775807}{1000 \times 60 \times 60 \times 24 \times 365} \approx 292,471,208 (年)

整整将近3亿年呢！虽然比不上地球的寿命，但是我相信人类到那个时候，要么全部灭亡了，要么早就发明出更先进的方法来记录时间了，所以大胆的用 timestamp 就行。

甚至你把这个数丢给 JavaScript 的 Date，你会得到：

new Date(9223372036854775807) // Invalid Date

啊哈，JS都觉得长到离谱了。所以完全不用担心。而且很多编程语言都支持64位整型的，比如：

那会不会有什么系统不走寻常路，要用32位来存储时间戳？

如果某个系统或者软件使用32位来存时间戳的，那么算上符号位，我们最多可以存这么多毫秒

2^{32-1} - 1 = 2147483647 (ms)

那么，这个时间戳是多少呢？

new Date(2147483647); // Mon Jan 26 1970 04:31:23 GMT+0800 (China Standard Time)

居然还是1970年欸！

换句话说，但凡有系统用32位存储时间戳，早就出现类似千年虫的问题了，根本走不到现在。

我本以为分析到这边就结束了，但是我又想起来好像之前看到过什么2038年问题的，我又去搜了一下，确实有：unix时间戳_百度百科。不过这个问题在 Linux内核5.6 已经解决：技术|四大亮点带你看 Linux 内核 5.6

话都到嘴边了，那就浅浅聊聊这个2038年问题吧：之前Unix的时间戳是以32位存储的，单位是秒，也就是说之前32位的 UNIX 最多可以存 $2147483647s$ ，也就是 $2147483647000ms$ 。这个数值对应的时间是多少呢：

new Date(2147483647000) // Tue Jan 19 2038 11:14:07 GMT+0800 (China Standard Time)

嗯，确实是 2038 年。不过还好已经解决了。

时间戳会溢出吗？理论上会，但是那是将近 3 亿年之后的事情了。人类到那个时候，要么全部灭亡了，要么早就发明出更先进的方法来记录时间了。至于 UNIX 的 2038 年问题，也已经在 Linux内核5.6 解决。所以完全不用担心。