为什么 Unix 时间从 1970-01-01 开始？为什么不是 1971-01-01 或任何其他日期？
答案1
答案2
Unix 并不是诞生于 1970 年。
Unix 纪元是 1970 年 1 月 1 日午夜。重要的是要记住，这不是 Unix 的“生日”——操作系统的粗略版本出现在 20 世纪 60 年代左右。相反，据丹尼斯·里奇（Dennis Ritchie）所说，日期在 70 年代初的某个时候被编程到系统中，只是因为这样做很方便，丹尼斯·里奇（Dennis Ritchie）是贝尔实验室成立之初从事 Unix 工作的工程师之一。
答案3
我喜欢这个问题:-)
让我尝试回答一下（当然来源：互联网）
Unix 时间由 32 位整数（整数）表示，可以是正数或负数（有符号）。 Unix 最初是在 60 年代和 70 年代开发的，因此 Unix 时间的“开始”被设置为 1970 年 1 月 1 日午夜 GMT（格林威治标准时间） - 该日期/时间被分配 Unix 时间值 0。这是已知的作为 Unix 纪元。
32 位有符号整数可以表示 -2147483648 到 2147483647 之间的整数。由于 Unix 时间从 0 开始，负 Unix 时间值从纪元开始按时间倒退，而正数则按时间前进。这意味着 Unix 时间范围从 1901 年 12 月 13 日的 Unix 时间值 -2147483648 或 20:45:52 GMT 到 2038 年 1 月 19 日的 Unix 时间值 2147483647 或 3:14:07 GMT。这些日期代表开始、史前和 Unix 时间的结束。
Unix 时间将于 2038 年 1 月 19 日 03:14:07 GMT 结束。 2038 年 1 月 19 日 03:14:08 GMT 所有仍使用 32 位 Unix 时间的计算机将发生溢出。这就是所谓的“2038年问题”。一些人认为这将是一个比“2000年问题”更严重的问题。 2038 年问题的解决方法是将 Unix 时间存储为 64 位整数。大多数 64 位操作系统已经开始这样做，但许多系统可能不会在 2038 年之前更新。
答案4
引用我的答案来自 SE.Retrocomputing，为什么 Unix 纪元是 1970 年 1 月 1 日？:
这JdeBP 的评论引起了我的兴趣：
嘘！丹尼斯·里奇向波尔-亨宁·坎普、沃伦·图米和《连线》杂志记录了此事。 Warner Losh 也对此进行了报道...了解 dmr 实际上告诉了人们这件事。
因此，这里是丹尼斯·里奇对此的评论，以及他提到的溢出的简要解释。
Unix 纪元是 1970 年 1 月 1 日午夜。重要的是要记住，这不是 Unix 的“生日”——操作系统的粗略版本大约在 1960 年代。相反，据丹尼斯·里奇（Dennis Ritchie）所说，日期在 70 年代初的某个时候被编程到系统中，只是因为这样做很方便。丹尼斯·里奇（Dennis Ritchie）是贝尔实验室成立之初从事 Unix 工作的工程师之一。
”当时我们没有磁带，而且运行着几个文件系统，我们不断地改变时间的起源，”他说。“所以最后我们说，‘让我们选择一个不会在一段时间内溢出的东西。尽管。' 1970 年似乎和任何一个年份一样美好。”
一年大约有3200万秒，这意味着10亿秒过去大约需要31年。显然，今年早些时候，一些数学爱好者发现 2001 年是 1970 年以来的 31 年，他们中的一些人认为这可能代表“溢出”——日期缓冲区填充了数字，导致计算机变得古怪。
此外，还有更多历史细节，华纳·洛什在一封电子邮件中指出，回复：[TUHS] 2038 bug...，2021 年 1 月 4 日：
我的理解是，从 1970 年 1 月 1 日起，至少从 Ed5 开始，如果不是 Ed6 的话。
从第四版开始就是这样。
在第三版中，它是自 1972 年以来 60Hz 滴答数，并附有这样的注释：“这保证了每 2.26 年就会发生一次危机。”
重新确定纪元的基数将是……棘手的……大量的数学计算都是假设起源于 1970 年，而且即使是一致的分析，也并非所有的计算都是显而易见的。
不太难看的是声明 time_t 为无符号而不是有符号...它会破坏更少的代码...使 time_t 64 位也会破坏代码，即使您声明您不关心二进制兼容性，因为许多旧应用程序都知道 time_t是32位的。
华纳