UNIX 时间戳
延伸阅读：Y2K38 错误
2038年问题又叫Unix千年臭虫或Y2K38错误。在时间值以带符号的32位整数来存储或计算的数据存储情况下，这个错误就有可能引发问题。
可以用Unix带符号的32位整数时间格式来表示的最大时间是 2038年1月19日03:14:07UTC（2038-01-19T03:14:07Z），这是自 1970-01-01T00:00:00Z 之后过了 2147483647 秒，值的边界如下：
时间 | 时间戳 | 二进制字面量 |
1970-01-01T00:00:00Z | 0 | 00000000 00000000 00000000 00000000 |
2038-01-19T03:14:07Z | 2^31-1, 2147483647 | 01111111 11111111 11111111 11111111 |
测试代码：
// 0
long a = 0;
// 2^31-1, 2147483647
long b = Integer.MAX_VALUE;
// 1970-01-01T00:00:00.000Z
Instant.ofEpochSecond(a).atZone(ZoneOffset.of("-00:00")).toLocalDateTime()
// 2038-01-19T03:14:07.000Z
Instant.ofEpochSecond(b).atZone(ZoneOffset.of("-00:00")).toLocalDateTime()过了最大时间后，由于整数溢出，时间值将作为负数来存储，系统会将日期读为1901年12月13日，而不是2038年1月19日。
用简单的语言来说，Unix机器最终将会耗尽存储空间来列举秒数。所以，到那一天，使用标准时间库的C程序会开始出现日期问题。
下面这个动画显示了2038年错误将如何重置日期：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
目前，2038年错误没有什么通行的解决方案。如果对用于存储时间值的time_t数据类型的定义进行更改，依赖带符号的32位time_t整数性质的应用程序就会出现一些代码兼容性问题。假设time_t的类型被更改为不带符号的32位整数，那将加大最新的时间限制。但是，这会对由负整数表示的1970年之前的日期造成混乱。
使用64位架构的操作系统和程序使用64位time_t整数。使用带符号的64位值可以将日期延长至今后的2920亿年。
已有人提出了许多建议，包括以带符号的64位整数来存储自某个时间点（1970年1月1日或2000年1月1日）以来的毫秒/微秒，以获得至少30万年的时间范围。其他建议包括用新的库重新编译程序，等等。这方面的工作正在开展之中；据专家们声称，2038年问题解决起来应该不难。
参考
