1970年1月1日是什么梗

不知道你是否时常在各种网站，社交平台，观察到这样一个神秘时间。1970年1月1日零点，或是1970年1月1日上午8点。你是否思考过这样一个不符合情理的1970年，究竟是如何被程序员不小心呈现给你的。

今天我们就来揭秘1970年1月1日背后的的历史和故事。

要解开这里的秘密，我们需要先了解一下 Unix 时间。

Unix 时间起源于 Unix 操作系统，广泛应用于计算机操作系统、文件系统、编程语言和数据库。它将 1970年1月1日星期四的 00:00:00 UTC 作为起始时间，以经过的秒数来表示当前时间，因此也叫 Unix 时间戳。在现代计算机中，Unix 时间的粒度可以是秒、也可以是微秒或者纳秒。

Unix 时间对计算机十分友好，它的存储和计算都非常简单，且它不受时区影响，无论在哪里，都可以精确地表示某一刻的时间，比如：Unix 时间戳 0 即为1970年1月1日的零点，Unix(1718542487) 即为 2024年6月16日 的 12:54:47。

你可能还注意到后面这个 +00:00，这和 UTC 时间有关。

UTC 全称 Coordinated Universal Time，表示协调世界时。主要用于协调世界不同时区的时间，让大家统一表示某一刻的时间，有时 UTC 后面会加上一个数字用来表示时区。

我们知道，世界上不同地区是存在时差的，或者说人们为不同地区划分了时区。比如，UTC+0 或者 (UTC) 表示英国时间、格林威治时间等，我们常听到的东八区（UTC+8），表示的就是北京时间或是新加坡等地区的时间。

之前说 Unix(0) 表示1970年1月1日的零点，准确说是 UTC+0 这个时区的零点。如果用北京时间表示，则为 1970年1月1日的上午8点。这两个时间本质上是同一时刻，只是时区不同。

知道了 Unix 时间和 UTC 时间后，我们就可以对 1970 年问题进行解密了。

我们知道 Unix(0) 在 UTC+0 时区上的时间为1970年1月1日的零点，那么图片中的错误时间背后是不是就是用了 Unix(0) 呢？

的确如此，不过这很可能是程序员不小心造成的，比如逻辑考虑不周或者软件测试过程不充分导致。

例如，在前端 JS 语言中，程序员可以使用 new Date(timestamp) 来生成一个时间对象：

假设这里 timestamp 变量来自数据库或者其他地方，那么在一些情况下，程序可能由于网络或系统故障问题，得到一个空值，比如：null，那么此时 new Date(null) 就会默认为 Unix(0)，然后被格式化为本地时间，最终显示成 1970年1月1日的 8 点。

当然，实际情况可能更加复杂，稍不留神就可能导致严重的后果。比如2016年，将苹果手机时间设置为1970年后会让手机变砖，很可能就是对 Unix 时间处理不当导致。

除了刚才提到的 1970 年问题，其实还有一个 2038 年问题也值得关注，如果你有幸在 2038 年的新闻中看见相关报道，记得回来点赞，前提是视频还在。

在早期 32 位计算机系统中，Unix 时间戳用 32 位有符号整数存储，第一位是符号位，最大可以表示的整数是 2147483647，转换成时间就是 2038年1月19日3点14分07秒。如果时间再过去1秒，那么符号位变成1，整数变为最小负数，时间就变成了 1901年12月13日20点45分52秒，一下子回到了 138 年前。

虽然目前绝大多数计算机系统，已经不再采用 32 位有符号整数来存储 Unix 时间戳，而是 64 位，它表示的时间已经远远超过人类灭亡需要的时间了。但是直到 2022 年，世界上还有数以亿计的操作系统还在使用 32 位存储，特别在那些难以得到升级的嵌入式设备中，它们将在 2038 年集中爆发故障。

Unix 时间作为一种简单、高效的时间表示方法，在计算机科学和信息技术领域发挥了重要作用。它不仅简化了时间管理和计算，还为现代操作系统、编程语言和应用程序提供了一个统一的时间标准。无论它是隐藏在 1970 年 bug 背后，或是即将导致 2038 年问题，Unix 时间的理念和设计仍将在未来，继续影响和推动技术发展。