为啥 1/1/1970 是“纪元时间”？

Posted 2023-02-19

【中文标题】为啥 1/1/1970 是“纪元时间”？

【英文标题】：Why is 1/1/1970 the "epoch time"?为什么 1/1/1970 是“纪元时间”？

【发布时间】：2010-11-08 14:50:40

【问题描述】：

为什么

1970 年 1 月 1 日 00:00:00

考虑到纪元时间？

【问题讨论】：

不知道为什么有人认为这是主观的。 'Epoch' 时间是标准的时间戳方案。

今天是 380,000 小时前

我们应该从这个日期开始计算时间，所以我们现在是第 44 年。

今天，现在，是1499969999！它只是大约。还有 8 小时！

@LeonardoRaele 是的！那么例如，第二次世界大战开始于公元前 31 年！

【参考方案1】：

早期版本的 unix 以 1/60 秒为间隔测量系统时间。这意味着 32 位无符号整数只能表示小于 829 天的时间跨度。出于这个原因，数字0（称为epoch）所代表的时间必须设置在最近的过去。由于这是在 1970 年代初期，因此将时代设置为 1971-1-1。

后来，系统时间改为每秒递增，这将可以用 32 位无符号整数表示的时间跨度增加到大约 136 年。由于从计数器中挤出每一秒不再那么重要，因此时代被四舍五入到最接近的十年，因此成为 1970-1-1。人们必须假设这被认为比 1971-1-1 更整洁。

请注意，使用 1970-1-1 作为其纪元的 32 位 有符号 整数可以表示直到 2038-1-19 的日期，在该日期它将环绕到 1901-12-13。

【讨论】：

1/60跟美国电网的频率有关系吗？

这是当时使用的系统板上的振荡器之一的频率。振荡器不必为 60Hz，因为它在 DC 上运行，但使用当时最常见的任何东西可能很便宜，当时电视正在大量生产......

实际上，在当时，计算机时钟和 RTC 与美国电源波形同步非常普遍，因为它（是？）非常可靠。乘以得到处理器时钟，除以得到 RTC 的秒数。

@mafioso：好的，我会在笔记本电脑上设置 2038-... 1901-12-13 的提醒。

@JediKnight 这是基于我自己作为开发人员的经验的推测：更改标准需要时间，如果您的更改没有生效，那么您最终会得到competing standards。 epoch 问题的真正解决方案是 64 位整数，而不是及时向前移动 epoch。

【参考方案2】：

History.

Unix 时间的最早版本有 以 a 递增的 32 位整数 60赫兹的速率，这是速率 硬件上的系统时钟 早期的 Unix 系统。价值 60 Hz仍然出现在某些软件中 结果是接口。时代也 与当前值不同。 第一版 Unix程序员手册 日期为 1971 年 11 月 3 日的定义 Unix 时间为“从 00:00:00 开始的时间， 1971 年 1 月 1 日，以六十分之一衡量 一秒钟”。

【讨论】：

纪元时间是 1970 年 1 月 1 日，而不是 1971 年 1 月 1 日。

@SteveHarrison 是，但一开始并不是这样

【参考方案3】：

http://en.wikipedia.org/wiki/Unix_time#History 稍微解释了 Unix 时间的起源和所选择的时代。 unix 时间和纪元日期的定义在稳定下来之前经历了一些变化。

但它没有说明为什么最终选择了 1/1/1970。

***页面的重要摘录：

第一版 Unix Programmer's Manual 日期为 1971 年 11 月 3 日，将 Unix 时间定义为“从 1971 年 1 月 1 日 00:00:00 开始的时间，测量六十分之一秒”。

由于 [the] 范围有限，在将速率更改为 1 Hz 并将历元设置为其当前值之前，历元被多次重新定义。

后来的几个问题，包括当前定义的复杂性，都是由于 Unix 时间是由用法逐渐定义的，而不是从一开始就完全定义的。

【参考方案4】：

纪元参考日期

epoch reference date 是时间线上的一个点，我们从该点开始计算时间。该点之前的时刻用负数计数，之后的时刻用正数计数。

使用多个时代

为什么将 1970 年 1 月 1 日 00:00:00 视为纪元时间？

不，不是 时代， 时代。 使用了许多时期。

这个时期的选择是任意的。

主要的计算机系统和库至少使用couple dozen various epochs 中的任何一个。最受欢迎的时代之一通常称为Unix Time，使用您提到的 1970 UTC 时刻。

虽然很受欢迎，但 Unix 时间的 1970 年可能不是最常见的。最常见的还有 1900 年 1 月 0 日，用于无数 Microsoft Excel 和 Lotus 1-2-3 电子表格，或 2001 年 1 月 1 日，Apple 的 Cocoa 框架在全球超过 10 亿台 iOS/macOS 机器中的无数应用程序中使用。或者GPS 设备使用的可能是 1980 年 1 月 6 日？

许多粒度

不同的系统在计算时间时使用不同的粒度。

即使是所谓的“Unix 时间”也各不相同，有些系统计算整个 seconds，有些计算 milliseconds。许多数据库如 Postgres 使用microseconds。一些，例如 Java 8 及更高版本中的现代 java.time 框架，使用nanoseconds。有些还使用其他粒度。

ISO 8601

由于在使用 epoch 参考和粒度方面存在很大差异，因此通常最好避免将时刻作为 count-from-epoch 进行通信。在 epoch 和粒度的模糊性，加上人类无法感知有意义的值（因此错过错误值）之间，使用纯文本而不是数字。

ISO 8601 标准提供了大量实用且精心设计的格式，用于将日期时间值表示为文本。这些格式很容易被机器解析，也很容易被跨文化的人类阅读。

这些包括：

仅限日期：2019-01-23 时刻在UTC: 2019-01-23T12:34:56.123456Z 时刻与offset-from-UTC: 2019-01-23T18:04:56.123456+05:30 week-based-year 周：2019-W23 Ordinal date（一年中的第 1 天到第 366 天）：2019-234

【参考方案5】：

简短回答：为什么不呢？

更长的答案：时间本身并不重要，只要每个使用它的人都同意它的价值。由于 70 年 1 月 1 日已经使用了很长时间，使用它可以让尽可能多的人尽可能地理解代码。

选择一个任意的时代只是为了与众不同并没有什么好处。

【讨论】：

因为 Unix 于 1969 年开发并于 1971 年首次发布，因此可以合理地假设没有机器必须表示早于 1970-01-01-00:00:00 的系统时间。

作为历史模拟游戏的开发者，某些时间对象的设计者倾向于假设所有程序只想表示未来或最近过去的日期，这似乎很愚蠢。当然，我们可以对自己的表示进行编程，或者在调整因子中工作，但仍然如此。

同样的前纪元问题也适用于“实际”的非游戏用途，例如商业电子表格、科学数据展示、时间机器 UI 等。

@Dronz 您必须考虑到这是为一台价值 72000 美元、具有 9KB RAM 的计算机设计的，该计算机使用晶体管和二极管作为逻辑门作为 CPU（当时没有芯片！）。因此，让最基本的东西起作用并不“愚蠢”。

OP 在元层面上是正确的，我们为时间制定的方案一直是相当随意的。一年的天数，一个月的天数，年“0”，闰年的规则……疯狂。每个系统都只是一系列糟糕的妥协，因为这是他们利用可用技术所能做的最好的事情，并且对于他们的直接用例来说工作得很好。所有工程项目都是如此：)