转载
https://juejin.im/post/5ee6eb8751882542f448aa43
问题复现
1970-01-01对于开发者来说都是不陌生的，有些系统对于时间的处理如果不够好的话，就可能把时间显示成1970-01-01，所以经常有用户看到1970-01-01这个时间。
这种情况其实是很简单就可以复现的，当我们尝试使用以下Java代码定义时间：
@Test public void date0Test() { // Date date = new Date(0); System.out.println(date); }
打印出来的结果：
Thu Jan 01 08:00:00 CST 1970
通过Date的构造函数的Java Doc说明我们也能得到一些蛛丝马迹：
1 /**
2 * Allocates a Date object and initializes it to
3 * represent the specified number of milliseconds since the
4 * standard base time known as "the epoch", namely January 1,
5 * 1970, 00:00:00 GMT.
6 *
7 * @param date the milliseconds since January 1, 1970, 00:00:00 GMT.
8 * @see java.lang.System#currentTimeMillis()
9 */
10 public Date(long date) {
11 fastTime = date;
12 }
该构造函数接收用户指定一个毫秒数，如new Date(1000)，表示获得一个距离"epoch"有1000毫秒的时间。在Java中，这个时间是1970, 00:00:00 GMT。
至于"epoch"是个啥呢? 这个一般认为是"纪元时间", 直接认为是1970-01-01就行了!
那为啥"纪元时间"就是1970-01-01呢? 这就要从Unix操作系统诞生开始说起
时间戳
1969年8月，贝尔实验室的程序员肯汤普逊利用妻儿离开一个月的机会，开始着手创造一个全新的革命性的操作系统，他使用B编译语言在老旧的PDP-7机器上开发出了Unix的一个版本。
随后，汤普逊和同事丹尼斯里奇改进了B语言，开发出了C语言，重写了Unix，新版于1971年发布。
在Unix被发明出来之后，需要在Unix上表示时间，就需要想办法定义一个能表示一份数据在某个特定时间之前已经存在的、完整的、可验证的数据来表示时间。
于是，Unix时间戳被定义出来，即通过当前时间和一个"纪元时间"进行对比，其间相差的秒数作为时间戳。
为了让Unix时间戳表示时间这种方式用的尽可能久，最初就把Unix诞生的时间1971-1-1定义成"纪元时间"。
其实最开始确实"纪元时间"用的是1971-1-1的, 不过后来又有过变化, 变化还不止一次, 每一次的原因也不同
时间戳修改
除了开始时间是1971-1-1而不是1970-1-1外，最初的时间戳也不是每增加1秒时间戳就变动一次，而是每1/60秒都会改变一次时间戳。
另外，Unix是在1971年发明出来的，当时的计算机系统是32位，如果用32表示有整数，那么最大值是2147483647(2^31-1)。
那么，简单做一个数学计算，如果用当时的时间戳计算方式来表示时间的话，Unix时间戳最多可以使用4294967296/（60*60*24）/60 = 828.5天（一天有60*60*24秒，每1/60秒会占用一个时间戳）。
想象一下，设计出一个计算机系统，他的时间只能表示 828.5天，是不是很难让人接受，但是最初的Unix确实是这样的。
后来，Unix的开发者们也渐渐意识到这样不是长久之计，于是开始做出改变。
最开始，他们将每1/60秒改变一次时间戳修改成每1秒改变一次时间戳。这样时间戳可以表示的时间就又放大了60倍。这时候有828.5*60/365 = 136年。
这时候，一方面136年已经足够久了，纪元时间稍微向前调一下影响也不大。另外一方面为了方便记忆和使用。
于是就把纪元时间从1971-01-01调整到1970-01-01了。
于是，随着后面各种开发语言的诞生，就都沿袭了1970-1-1这个设定。
所以，通常我们说的时间戳，就是指格林威治时间（GMT）1970年01月01日00时00分00秒起至现在的总秒数。
那问题来了, 如果只能用136年, 那岂不是2106年之后的计算机时间就不能用了? 其实不是的, 因为现在计算机已经不是当时的32位系统了, 目前64位已经很普遍了, 64位系统可以表示292,277,026,596年(2000多亿), 这样就不怕了
纪元时间与时区
我们前面所提到的纪元时间的设置，都是基于格林威治标准时间的，即GMT时间。
但是世界上各个地区有自己的时区，都需要基于GMT时间进行调整。
所以1970-01-01 08:00:00的显示显然是受到了时区的影响，因为中国处于东八区，所以时间会比标准时间早8小时，而标准时间应该是1970-01-01 00:00:00。
应该很多人都记得《苹果"1970 事件"》，在几年前，一个名为vista980622的网友在国外网站Reddit的论坛上发表了一篇“把iPhone时间改成1970年1月1日，手机即可永远变砖”的帖子。
在该帖子发布不久，很多人都不相信，抱着试试看的态度将手机的时间设置成1970年1月1日，结果手机关机后重新开机真的变砖了。
因为我们处于东八区，时间比标准时间要快8小时，如果我们把时间调整成1970-01-01 00:00:00，那么标准时间就会是比这个时间少8小时，即1969年12月31日16时0分0秒。
但是，IOS设备是以UTC时区(GMT时间)的1970年1月1日0点0时0秒为界限，数值为0，用户把时间调整到1969年12月31日16时0分0秒，系统就要出现负值的时间。
系统版本为IOS 8.0至IOS 9.3 beta3，并且搭载64位处理器(即处理器为A7-A9X的设备)的苹果设备都会触发这个Bug，导致变砖！