子舒的博客
·
为什么 getTime() 返回 1970 年至今的毫秒？
内容提要
Java 和 UNIX 系统的时间起点为 1970 年 1 月 1 日，32 位系统的最大时间限制为 68 年，未来的 64 位系统将解决时间回归问题。时间差异源于时区设置。
关键要点
-
Java 和 UNIX 系统的时间起点为 1970 年 1 月 1 日。
-
getTime() 方法计算从 1970 年 1 月 1 日至今的毫秒数。
-
UNIX 系统认为时间纪元是 1970 年 1 月 1 日 0 点。
-
32 位系统的最大时间限制为 68 年，最大值为 2147483647。
-
2038 年 1 月 19 日将达到 32 位系统的最大时间，可能导致时间回归问题。
-
64 位系统将解决时间回归问题，可以表示到 292,277,026,596 年。
-
打印的时间与系统时区设置有关，实际时间为 0 点，但因时区显示为 8 点。
延伸解读
时间起点的历史背景
1970年1月1日被选为时间起点，源于UNIX系统的设计。这个时间点的选择反映了当时计算机技术的局限性，32位系统只能表示68年的时间范围，这也影响了后续编程语言的时间处理方式。
32位与64位系统的区别
32位系统在2038年将面临时间回归问题，可能导致软件异常。相比之下，64位系统可以表示更长的时间范围，解决了这一限制。因此，未来的系统升级将是确保时间处理准确性的关键。
时区对时间显示的影响
在使用getTime()方法时，打印的时间与系统时区设置有关。尽管实际时间为0点，但因时区不同，显示结果可能会有所偏差。了解这一点有助于开发者在处理时间时避免混淆。
延伸问答
为什么 getTime() 方法从 1970 年 1 月 1 日开始计算时间？
因为 UNIX 系统将 1970 年 1 月 1 日 0 点视为时间纪元，Java 也沿用了这一习惯。
32 位系统的时间限制是什么？
32 位系统的最大时间限制为 68 年，最大值为 2147483647。
2038 年会发生什么问题？
到 2038 年 1 月 19 日，32 位系统将达到最大时间，可能导致时间回归问题。
64 位系统如何解决时间回归问题？
64 位系统可以表示到 292,277,026,596 年，解决了32位系统的时间限制问题。
为什么打印的时间与实际时间不同？
打印的时间受系统时区设置影响，实际时间为 0 点，但因时区显示为 8 点。
Java 中如何获取当前时间的毫秒数？
可以使用 new Date().getTime() 方法获取从 1970 年 1 月 1 日至今的毫秒数。
