简单的回答:为什么不呢?

长一点的回答:时间本身并不重要，只要每个使用它的人都认同它的价值。由于1/1/70已经使用了很长时间，使用它会让你的代码尽可能为更多人所理解。

为了与众不同而任意选择一个时代并没有太大的好处。

历史。

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时间和epoch日期的定义在稳定在现在的水平之前经历了几次更改。

但它并没有说明为什么最终选择了1970年1月1日。

维基百科页面上值得注意的摘录:

1971年11月3日第一版《Unix程序员手册》将Unix时间定义为“1971年1月1日00:00:00以来的时间，以六十分之一秒为单位”。 由于范围有限，在速率更改为1 Hz并将epoch设置为其当前值之前，epoch被重新定义了不止一次。 后来的几个问题，包括目前定义的复杂性，都是由于Unix时间是根据使用情况逐渐定义的，而不是从一开始就完全定义的。

unix的早期版本以1/60秒为间隔测量系统时间。这意味着32位无符号整数只能表示小于829天的时间跨度。因此，由数字0表示的时间(称为epoch)必须设置在最近的过去。由于这是在20世纪70年代初，所以时代定在1971年1月1日。

后来，系统时间被更改为每秒钟增加一次，这将可以用32位无符号整数表示的时间跨度增加到136年左右。由于从计数器上挤出每一秒已经不再那么重要，纪元被四舍五入到最近的十年，从而变成了1970-01-01。人们肯定会认为这比1971年1月1日稍好一些。

注意，使用1970-01-01作为epoch的32位有符号整数可以表示到2038-01-19的日期，该日期将环绕到1901-12-13。

纪元参考日期

纪元参考日期是时间轴上的一个点，我们从这个点开始计算时间。在这一点之前的时刻以负数计算，在这一点之后的时刻以正数计算。

使用的时代很多

为什么1970年1月1日00:00:00被认为是epoch ?

不，不是时代，是一个时代。有许多时代在使用。

这种时代的选择是任意的。

主要的计算机系统和图书馆使用至少几十个不同时代中的任何一个。最流行的时代之一通常被称为Unix时间，使用您提到的1970 UTC时刻。

Unix Time的1970虽然很流行，但可能不是最常见的。最常见的还有1900年1月0日，无数微软Excel和Lotus 1-2-3电子表格，或者2001年1月1日，苹果Cocoa框架在全球超过10亿台iOS/macOS机器上的无数应用程序中使用。或者GPS设备使用的1980年1月6日?

许多粒度

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

即使是所谓的“Unix时间”也各不相同，有些系统计算整秒，有些则计算毫秒。许多数据库，如Postgres使用微秒。有些，比如现代的java。在Java 8及以后版本中，时间框架使用纳秒。有些人还使用其他颗粒。

ISO 8601

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

ISO 8601标准提供了一套广泛的、设计良好的实用格式，用于将日期-时间值表示为文本。这些格式很容易被机器解析，也很容易被不同文化的人阅读。

这些包括:

只记录日期:2019-01-23 时间UTC时间:2019-01-23T12:34:56.123456Z offset-from-UTC: 2019-01-23T18:04:56.123456+05:30 以周为单位的年份:2019-W23 序号日期(每年的第1至366天):2019-234