我们知道在Java中System.currentTimeMillis()方法来获取系统当前时间与1970年1月1日0点之间的毫秒差距。而在.NET中也有System.Environment.TickCount()方法来获取与1970年1月1日0点之间的毫秒差距,这个1970.01.01 00:00:00就是系统的最小时间,那么为什么系统的最小时间是这个,而不是0001.01.01 00:00:00呢?
这个还是要从计算机的构造说起,可以追溯到Unix操作系统。UNIX系统认为1970年1月1日0点是时间纪元,所以我们常说的UNIX时间戳是以1970年1月1日0点为计时起点时间的。
计算机是怎么计时间的呢?设定一个时间的最小值,然后设置一个变量,每过一秒,这个变量就加1.所以当前时间就是最小时间与变量的和。最初计算机操作系统是32位,而时间也是用32位表示。32位能表示的最大值是2147483647。另外1年365天的总秒数是31536000,2147483647/31536000= 68.1,也就是说32位能表示的最长时间是68年,也就是说,以当时的计算机水平,能够记住的时间最多是68年,因为那个变量最多能够存那么多秒数。那时候20世纪中后期,那时候人们就需要制定时间的最小值啊。总不能是0001年吧,那即使加上68年也远远没到那会的时间啊。最终综合考量,决定把1970年1月1日0点定位最小值。因为那时候32位系统足以解决那个年头的计数问题。
现在我们思考,如果是1970年是最小年头,32位系统的话,那么到了2038年01月19日03时14分07秒(这个就是32位能够记住的最大的数),时间还是会回归到最小值。
上边说过了,那时候是七八十年代,已经足以解决当时的问题了。他们想,2038年出现问题,就让那时候的后代去解决吧。事实上他们是对的,因为现在我们已经解决了这个问题,就是64位系统,因为用64位操作系统可以表示到292,277,026,596年12月4日15时30分08秒,相信我们的N代子孙,哪怕地球毁灭那天都不用愁不够用了,因为这个时间已经是千亿年以后了。
正如中国政府对南海问题持有的态度,让后代去解决吧,我们把眼前的事情解决了就行,搁置争议,共同开发。