为什么
1970 年 1 月 1 日 00:00:00
考虑到纪元时间？
【问题讨论】：
早期版本的 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。
【讨论】：
Unix 时间的最早版本有 以 a 递增的 32 位整数 60赫兹的速率，这是速率 硬件上的系统时钟 早期的 Unix 系统。价值 60 Hz仍然出现在某些软件中 结果是接口。时代也 与当前值不同。 第一版 Unix程序员手册 日期为 1971 年 11 月 3 日的定义 Unix 时间为“从 00:00:00 开始的时间， 1971 年 1 月 1 日，以六十分之一衡量 一秒钟”。
【讨论】：
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 时间是由用法逐渐定义的，而不是从一开始就完全定义的。
【讨论】：
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。有些还使用其他粒度。
由于在使用 epoch 参考和粒度方面存在很大差异，因此通常最好避免将时刻作为 count-from-epoch 进行通信。在 epoch 和粒度的模糊性，加上人类无法感知有意义的值（因此错过错误值）之间，使用纯文本而不是数字。
ISO 8601 标准提供了大量实用且精心设计的格式，用于将日期时间值表示为文本。这些格式很容易被机器解析，也很容易被跨文化的人类阅读。
这些包括：
2019-01-23
2019-01-23T12:34:56.123456Z
2019-01-23T18:04:56.123456+05:30
2019-234 【讨论】：
简短回答：为什么不呢？
更长的答案：时间本身并不重要，只要每个使用它的人都同意它的价值。由于 70 年 1 月 1 日已经使用了很长时间，使用它可以让尽可能多的人尽可能地理解代码。
选择一个任意的时代只是为了与众不同并没有什么好处。
【讨论】：