为什么 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位的。
华纳